Hi,
Thinking about this a bit, I get quite at unease. Initially I understood
ujax as a two-part protocoll: A client-side and a server-side part. The
server-side part would care for accessing the storage while the
client-side would care for user interaction and GUI support. This IMHO
means, the protocol should be defined for "machine-machine" interaction
and leave the human interface to the client-side frontend.
Looking from this position, there are the following options:
* Send back success information for the client
* Redirect to the input form submitting the POST
* Redirect to the modified/created Resource
The main issue is the question of sending back success information,
because the other two cases can be handled by the ujax:redirect
parameter. Now for sending this information and keeping in mind the
separation of the tasks of client and server, I would just send back
plain machine readable information, that is JSON (parsing HTML is
error-prone at best ;-) ).
Therefore, I would really like to make it as simple as possible by
defining a new property ujax:response as follows and dropping
ujax:redirect:
ujax:response = ujax:status -> send back status info as JSON
ujax:response = *[ext] -> redirect to modfied/created Resource
where ext is used as the extension,
default .html
ujax:response = ujax:referer -> redirect to Referer:
As a default (when ujax:response property is missing), I suggest to
redirect to the created/modified Resource.
Am Samstag, den 02.02.2008, 14:13 +0100 schrieb Tobias Bocanegra:
> another thought: since the extension of a request pretty much
> determines what content should be returned, i suggest to use the
> extension to select the POST response:
>
> assume a resource at /foo/bar
>
> POST /foo/bar
> writes back changes and redirect per default to the referrer
Not sure...
> POST /foo/bar.html
> writes back changes and responds with the suggested HTML status response
Probably might also expect to just get the modified Resource back as
HTML ???
> POST /foo/bar.json
> writes back changes and responds with a JSON status response (tbd)
Same but as JSON ??
>
> for node creation:
>
> POST /foo/bar/*
> creates node, writes back changes and redirects to the newly created
> resource (default .html ext.)
> POST /foo/bar/*.html (or /foo/bar.html/*) ??
> creates node, writes back changes and responds with the HTML status response
> POST /foo/bar/*.json (or /foo/bar.json/*) ??
> creates node, writes back changes and responds with the JSON status response
These show exactly, the complexities of your proposal, all look bad and
ugly..
Regards
Felix
>
> things that at not very clear to be are:
> - needs the creation request to be /*.html or .html/* so that the
> resources .html extension mapped
> servlet does not get selected?
> - how can one still use a custom POST script for that resource ? maybe
> the extension for the
> HTML status response should be .xhtml ?
>
> regards, toby
>
> On 2/1/08, Tobias Bocanegra <[EMAIL PROTECTED]> wrote:
> > hi,
> > i've discussed this with david extensively and since he was the
> > inventor of the ujax (former rjax) "protocol" he thinks now that the
> > proposal to use the referer as default redirect is not useful.
> > it was also david that proposed the html response which is of a format
> > that it is human (browser response), machine (xml) and dhtml
> > (javascript) readable.
> >
> > i think it would be great to apply the patch of SLING-213 and forget
> > about the referer stuff of SLING-126.
> >
> > regards, toby
> >
> >
> > On 2/1/08, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> > > Hi all,
> > >
> > > I am trying to apply the patch of SLING-213 [1], which conains a rewrite
> > > of the ujax POST servlet. There is just one issue with this patch, which
> > > I would like to sort out on the list. This patch changes the response
> > > behaviour of the POST requests as follows:
> > >
> > > * The default response is a status 200 response containing a list of
> > > changes in HTML
> > > format
> > > * Setting the ujax:redirect request parameter to "*" causes a 302
> > > (temporary redirect)
> > > to the modified/created node
> > > * Setting ujax:redirect to an URL causes a 302 (temporary redirect)
> > > to the given URL
> > >
> > > This setting collides, with what was intended by SLING-126 [2], where a
> > > redirect to the Referer URL was postulated.
> > >
> > > I would now like to resolve this issue of the response to a POST
> > > request. Can you please enlighten me on that front ?
> > >
> > > My personal opinion would be to get redirected to the Referer by default
> > > (this is the standard GUI case, probably), with an option to redirect to
> > > a possibly newly created node (ujax:redirect is *) or - in the Ajax case
> > > - get a machine readable response, JSON that is.
> > >
> > > WDYT ?
> > >
> > > Regards
> > > Felix
> > >
> > > [1] http://issues.apache.org/jira/browse/SLING-213
> > > [1] http://issues.apache.org/jira/browse/SLING-126
> > >
> > >
> >
> >
> > --
> > -----------------------------------------< [EMAIL PROTECTED] >---
> > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> > T +41 61 226 98 98, F +41 61 226 98 97
> > -----------------------------------------------< http://www.day.com >---
> >
>
>
