You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@gmail.com> on 2008/02/01 20:34:33 UTC
SLING-213 vs. SLING-126
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
Re: SLING-213 vs. SLING-126
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Feb 2, 2008 2:13 PM, Tobias Bocanegra <to...@day.com> wrote:
> ...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.
Agreed, that's how Sling works for "normal" operations, so it's consistent.
> ...POST /foo/bar
> writes back changes and redirect per default to the referrer
> POST /foo/bar.html
> writes back changes and responds with the suggested HTML status response
> POST /foo/bar.json
> writes back changes and responds with a JSON status response (tbd)...
I would handle that a bit differently: IMHO, POST to an existing
Resource should be handled in a very simple way, with minimal ujax
functionality: in that case, I'd just allow creating/updating
Properties on the Resource.
My rationale here is: for such POSTs, you're talking to the Resource,
not to the "ujax engine".
And for POSTs using the "magic star":
> POST /foo/bar/*
> POST /foo/bar/*.html
> POST /foo/bar/*.json
I'd say "now, due to the use of the magic star, you are talking to the
ujax engine", which is a Resource that behaves in a different way than
standard Resources.
The ujax engine processes the request, creates a java UjaxResultObject
(simple thing, basically a list of what the ujax engine did), and this
object can be serialized in xhtml or json depending on the request's
extension. The xhml is both machine and human readable, with qualified
links to created and modified items, like <a href="newnode.html"
class="ujax_created">newnode.html</a>.
To summarize, compared to your proposal, the differences are:
a) POSTs to Resources that exist do not involve the full ujax engine,
they only allow updates to the Resource, using the ujax conventions on
request parameter names. No redirect is needed in this case, the
request simply returns the Resource's updated state.
b) POSTs to the "magic star" talk to the ujax engine, which allows
more operations (updates, creation of new nodes, deletes, moves,
etc.), with more options, and returns complete information, in HTML or
JSON, on what happened, with links to all created nodes.
I think this isolates the "special case" of ujax better: the star in
URLs is a good sign that something special is going on, but if it's
not used things remain very simple.
-Bertrand
Re: SLING-213 vs. SLING-126
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Feb 4, 2008 9:11 AM, Felix Meschberger <fm...@gmail.com> wrote:
> ...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...
Agreed, but should not necessarily stop us from making the protocol
human readable, if that has other benefits.
If Toby has a good use-case for XHTML status responses (like simple
HTML form-based interactions, which can be useful), and if we can
generate this XHTML in a safe and parsable way (read on for more about
that), no problem with me.
I'll reply separately to Toby's proposal about how to handle POSTs, as
I have a slightly different suggestion.
-Bertrand
Re: SLING-213 vs. SLING-126
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Feb 4, 2008 9:50 AM, Peter Svensson <ps...@gmail.com> wrote:
> There's a fairly good discussion here;
> http://extjs.com/forum/archive/index.php/t-4047.html...
Thanks, I'll have a look!
> ...Another tack (I think Google did this last year in response to a phishing
> Cross-domain trick for gmail) is to prepend a 'for(;;);' , which runs the
> attacker in circles :)...
Ooohhh - phishers, all your CPUs are belong to us ;-)
-Bertrand
Re: SLING-213 vs. SLING-126
Posted by Peter Svensson <ps...@gmail.com>.
There's a fairly good discussion here;
http://extjs.com/forum/archive/index.php/t-4047.html with several good
links. The basic idea is to make it impossible to use eval() to get the
data, so for instance the server could always put the JSON string between
'/*' and '*/', which will make a comment out of the string, thus hiding it
from any evaluation.
Another tack (I think Google did this last year in response to a phishing
Cross-domain trick for gmail) is to prepend a 'for(;;);' , which runs the
attacker in circles :)
Cheers,
PS
On Feb 4, 2008 9:31 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
> On Feb 4, 2008 9:20 AM, Peter Svensson <ps...@gmail.com> wrote:
>
> > ...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....
>
> Do you have a suggestion for this error inducing layer? Just a
> constant String before the JSON data, or something more sophisticated?
>
> -Bertrand
>
Re: SLING-213 vs. SLING-126
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Feb 4, 2008 9:20 AM, Peter Svensson <ps...@gmail.com> wrote:
> ...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....
Do you have a suggestion for this error inducing layer? Just a
constant String before the JSON data, or something more sophisticated?
-Bertrand
Re: SLING-213 vs. SLING-126
Posted by Peter Svensson <ps...@gmail.com>.
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 <fm...@gmail.com> 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 <to...@day.com> 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 <fm...@gmail.com> 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
> > > >
> > > >
> > >
> > >
> > > --
> > > -----------------------------------------< tobias.bocanegra@day.com>---
> > > 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>---
> > >
> >
> >
>
>
Re: SLING-213 vs. SLING-126
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Feb 4, 2008 9:49 AM, David Nuescheler <da...@day.com> wrote:
> ...(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....
ok
> ...(2) the returned xhtml contains identified and specified "Id" attributes
> that are used for machine readability....
ok, that's similar to my suggestion earlier in this thread, fine with that.
> ...(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)...
ok
> ...I think it would be great if the above was put into junit tests.,,
Sure - the launchpad-webapp integration tests already exercise the
ujax protocol, so it's only a matter of adding tests for the
new/improved stuff - including parsing of the returned xhtml.
-Bertrand
Re: SLING-213 vs. SLING-126
Posted by Felix Meschberger <fm...@gmail.com>.
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 <fm...@gmail.com> 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 <to...@day.com> 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 <fm...@gmail.com> 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
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > -----------------------------------------< tobias.bocanegra@day.com >---
> > > > 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 >---
> > > >
> > >
> > >
> >
> >
Re: SLING-213 vs. SLING-126
Posted by David Nuescheler <da...@day.com>.
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 <fm...@gmail.com> 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 <to...@day.com> 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 <fm...@gmail.com> 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
> > > >
> > > >
> > >
> > >
> > > --
> > > -----------------------------------------< tobias.bocanegra@day.com >---
> > > 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 >---
> > >
> >
> >
>
>
Re: SLING-213 vs. SLING-126
Posted by Felix Meschberger <fm...@gmail.com>.
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 <to...@day.com> 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 <fm...@gmail.com> 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
> > >
> > >
> >
> >
> > --
> > -----------------------------------------< tobias.bocanegra@day.com >---
> > 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 >---
> >
>
>
Re: SLING-213 vs. SLING-126
Posted by Tobias Bocanegra <to...@day.com>.
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
POST /foo/bar.html
writes back changes and responds with the suggested HTML status response
POST /foo/bar.json
writes back changes and responds with a JSON status response (tbd)
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
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 <to...@day.com> 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 <fm...@gmail.com> 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
> >
> >
>
>
> --
> -----------------------------------------< tobias.bocanegra@day.com >---
> 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 >---
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
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 >---
Re: SLING-213 vs. SLING-126
Posted by Tobias Bocanegra <to...@day.com>.
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 <fm...@gmail.com> 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
>
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
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 >---