I can't say that I follow all examples described properly, but in general I would very much agree that, wherever possible, only use 'raw' data between server and (Ajax/JavaScript) client. As soon as the server does View or redirects, things gets complicated quickly - for both sides.
So if it is at all possible, to ensure a clean protocol, try to send all information as XML or JSON. If you/we use JSON, I might also suggest to wrap it in an error-inducing layer, to be stripped by the client before eval(), to avoid JavaScript Cross-domain snooping. Cheers, PS On Feb 4, 2008 9:11 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > 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>--- > > > > > > > > >
