Hi all, Thanks for your replies. So I will take that route and modify the Sling-213 patch as described (notably the *[ext] variant).
Further, I close SLING-126 as won't fix as it is superceded by SLING-213. Regards Felix Am Montag, den 04.02.2008, 09:49 +0100 schrieb David Nuescheler: > Hi Guys, > > i had a quick chat with Felix and would like to propose the following: > > (1) since we are handling responses to POSTs that have to be both > machine readable and human readable and even more importantly > has to be handled gracefully by both XHR and "regular" browser POST > the default response needs to be text/html. Since also the regular > browser POST has to be "machine readable" we end up with the > following contract. > > (2) the returned xhtml contains identified and specified "Id" attributes > that are used for machine readability. The Id's used are as follows: > "Status", "Message", "Location", "ParentLocation", > "Path", "Referer", "ChangeLog" at this point. > The CDATA of the elements with the respective attributes contain > the values resulting from the POST operation. > "Location" and "ParentLocation" contain a (possibly rewritten) > "href" attribute with the same target information. > > (3) If the "ujax:redirect" parameter is used, it will either contain > a URL to be placed into the Location header of the 301/302 response, > or a reference to the "newly generated" resource using the "*" notation > (for example, "*.html, *.edit.html). > > I think it would be great if the above was put into junit tests. > Please let me know if that makes sense. > > regards, > david > > > On 2/4/08, 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 >--- > > > > > > > > > > > > > >
