Hi,
Am 29.04.2008 um 16:43 schrieb Felix Meschberger:
Am Dienstag, den 29.04.2008, 15:47 +0200 schrieb Alexander Saar:
and there will be another request parameter
which allows to override the response code for special case
handling
like hidden iframes in forms. This parameter could be named
sling:post:responseCodeOverride and the value could be the
response
code that should be used. If the parameter is not present the real
response code will be send.
and what do you do if you create and modify and delete several
resources at the same time? what response code do you send?
OK, that's indeed a problem I which I have not considered so far.
As I said, is this an issue with your Ajax use case ?
Not really for my current problem. I just want to create a bunch of
nodes for storing some data under a specific path and get a reference
to the nodes. This can be done easily with single AJAX requests if the
Location header is included in the response.
You should do one-operation per request there to have better control
anyway.
But what if you want to move a node? Does this mean I should do this
with three single requests? One for getting the content, one for
deletion and one for adding a new node.
we could include a flag that indicates the desired response:
:responseType="xml"
:responseType="json"
where "xml" is the default and always responds with a 200.
where "json" is a json representation of the response and also uses
the correct response codes.
What about using extensions to specify the desired behaviour?
This could look as follows:
POST to /foo -> 200 OK and a XHTML representation
POST to /foo.html -> 200 OK and a XHTML representation
POST to /foo.xml -> correct response codes and a XML
representation
POST to /foo.json -> correct response codes and a JSON
representation
What is the exact requirement and problem you want to solve with
this ?
In cases (1) and (2) we have the full information required. For use
case
(3) - Ajax - one operation at a time should be executed and thus
status
codes should be sufficient.
I was just trying to find a behaviour that one the one hand is suited
for all imaginable cases and which on the other hand is as much as
intuitive as possible. While playing around I also tried to get a JSON
response by adding a .json extension, which in my eyes shows that this
is an intuitive solution.
For case (1) and (2) I agree that everything needed is in place. For
(3) see my comment above.
If you need more inforamtion, I suggest you have XHR parse the XHTML
(which is XML) response and access the DOM.
But why should I deal with such annoying parsing of X(HT)ML in client
side JS if it is much easier to process a JSON definition?
For the first case I'm unsure if it would be better to send correct
response codes, header fields and a XHTML. Changing the behaviour
here
would break existing clients and thus all of them must be changed.
The first case - direct user form submission - is generally submitted
with a redirect request (in case of success). In case of failure, the
XHTML is sent with status 200 (yes!).
Sorry, I meant POST to /foo with "first case" and was not referring to
Tobis first case or (1). That was maybe not really clear.
Regards,
Alex
