[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
I would like to add my opinion.
I strongly believe that 204 is a success condition and should end up
calling the success callback with null for data (or possibly an empty
object {} if that would cause less backward compatibility problems)
and the actual status (in this case 204).
Parsererror is not the right status since there was nothing to parse.
The success callback has the status code and can make any decisions it
needs to based on it.
I think that viewing success from the protocol is the correct
perspective. So what if the ajax call said it would accept application/
json that just means that if there is a response that is the format I
would like it in. It REST it is very reasonable for a resource to
return 204. It may also return other status such as 200 if there is
data to return. So the REST client needs to be ready for either
*success* case.
As it currently stands I need to have checking in the error call back
to convert the error to success for the next layer up, which seems
ugly to me.
As someone pointed out all status codes 2xx, 3xx are success. Not sure
3xx status codes apply - doesn't XHR follow redirects on its own? Most
3xx cases are handled by XHR internally and the ones that are not are
already handled by jQuery. Anyway I agree that all 2xx, 3xx cases
should call the success callback.
I do not think individual callbacks for each status code are a good
idea.
Thanks,
-John
On Jul 24, 5:09 am, Nick Fitzsimons n...@nickfitz.co.uk wrote:
2009/7/23 John Resig jere...@gmail.com:
I guess that's a tangential issue, not really related to JSON - if a server
returns a204(with no content) should we call success with a null or
undefined data argument?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
One correction. The success callback gets only gets a text status. It
needs the HTTP status
so probably should pass in xhr object just as is done for the error
callback.
On Sep 7, 3:08 pm, John Snyders jjsnyd...@rcn.com wrote:
I would like to add my opinion.
I strongly believe that204is a success condition and should end up
calling the success callback with null for data (or possibly an empty
object {} if that would cause less backward compatibility problems)
and the actual status (in this case204).
Parsererror is not the right status since there was nothing to parse.
The success callback has the status code and can make any decisions it
needs to based on it.
I think that viewing success from the protocol is the correct
perspective. So what if the ajax call said it would accept application/
json that just means that if there is a response that is the format I
would like it in. It REST it is very reasonable for a resource to
return204. It may also return other status such as 200 if there is
data to return. So the REST client needs to be ready for either
*success* case.
As it currently stands I need to have checking in the error call back
to convert the error to success for the next layer up, which seems
ugly to me.
As someone pointed out all status codes 2xx, 3xx are success. Not sure
3xx status codes apply - doesn't XHR follow redirects on its own? Most
3xx cases are handled by XHR internally and the ones that are not are
already handled by jQuery. Anyway I agree that all 2xx, 3xx cases
should call the success callback.
I do not think individual callbacks for each status code are a good
idea.
Thanks,
-John
On Jul 24, 5:09 am, Nick Fitzsimons n...@nickfitz.co.uk wrote:
2009/7/23 John Resig jere...@gmail.com:
I guess that's a tangential issue, not really related to JSON - if a
server
returns a204(with no content) should we call success with a null or
undefined data argument?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
On Mon, Sep 7, 2009 at 3:19 PM, John Snydersjjsnyd...@rcn.com wrote: One correction. The success callback gets only gets a text status. It needs the HTTP status so probably should pass in xhr object just as is done for the error callback. This has been requested and a patch offered. But it hasn't been accepted yet. Not sure if that's due to focus on other things or resistance. http://dev.jquery.com/ticket/3591 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
On Mon, Sep 7, 2009 at 12:08 PM, John Snydersjjsnyd...@rcn.com wrote: I would like to add my opinion. ... I do not think individual callbacks for each status code are a good idea. Why? Do you not use XHR with services where you need to do different things depending on which 4xx code (for example) you receive back? Or do you just prefer to organize your branching as a switch/case or if/elseif within an error callback? In my current app, fairly different handlers are required for say, 401 than 405 or 404, and embedding the branching within switch/case or if/elseif is ugly and inflexible. This also happens to be a feature which would be much simpler and better to implement in the core ajax code than in a plugin. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
I don't see how passing you all the information is inflexible, on the contrary I would find writing a handler for a code and realizing there was another status code that needs the same handling to be what is really inflexible. If you have different handing based on different status codes then break up your handlers by what they do into diferent functions and simply write a switch statement that calls the relevant function. I don't see how that isn't flexible as the definition of flexibility in this case is the ability to bend the code to do something slightly different (like have a second status code share the handler of another) with easev(like adding a new case line into a switch). ~Daniel Friesen (DanTMan, Nadir Seen Fire) [http://daniel.friesen.name] On 7-Sep-09, at 3:24 PM, Nathan Bubna nbu...@gmail.com wrote: On Mon, Sep 7, 2009 at 12:08 PM, John Snydersjjsnyd...@rcn.com wrote: I would like to add my opinion. ... I do not think individual callbacks for each status code are a good idea. Why? Do you not use XHR with services where you need to do different things depending on which 4xx code (for example) you receive back? Or do you just prefer to organize your branching as a switch/case or if/elseif within an error callback? In my current app, fairly different handlers are required for say, 401 than 405 or 404, and embedding the branching within switch/case or if/elseif is ugly and inflexible. This also happens to be a feature which would be much simpler and better to implement in the core ajax code than in a plugin. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
On Sep 7, 6:24 pm, Nathan Bubna nbu...@gmail.com wrote: On Mon, Sep 7, 2009 at 12:08 PM, John Snydersjjsnyd...@rcn.com wrote: I would like to add my opinion. ... I do not think individual callbacks for each status code are a good idea. Why? In my apps the processing done for different status codes is mostly common. So it would be easier for me to just add a little branching as needed. But if I understand what is proposed the status code handler functions are optional and only called if defined. You can still use success and error if you like. So they wouldn't get in my way - it just doesn't seem worth it to me. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
On Mon, Sep 7, 2009 at 5:35 PM, Daniel Friesennadir.seen.f...@gmail.com wrote:
I don't see how passing you all the information is inflexible, on
the contrary I would find writing a handler for a code and realizing
there was another status code that needs the same handling to be what
is really inflexible.
then they should call the same handler. what does that have to do
with inflexibility? and even there:
options = { 404: handlerA, 405: handlerA, ... };
is nicer than:
options = { error: function(xhr) {
switch (xhr.statusCode) {
case 404:
case 405: handlerA(xhr); break;
}
}, ... };
If you have different handing based on different status codes then
break up your handlers by what they do into diferent functions and
simply write a switch statement that calls the relevant function. I
don't see how that isn't flexible as the definition of flexibility in
this case is the ability to bend the code to do something slightly
different (like have a second status code share the handler of
another) with easev(like adding a new case line into a switch).
they already are in different functions, and a switch statement is
simple to write. no argument. you see flexibility in terms of you
typing code. i am looking at it in terms of either myself type *or
other code composing an options object*. This is why i speak of
flexibility. More than one way to put together the code/options for
an ajax call.
~Daniel Friesen (DanTMan, Nadir Seen Fire) [http://daniel.friesen.name]
On 7-Sep-09, at 3:24 PM, Nathan Bubna nbu...@gmail.com wrote:
On Mon, Sep 7, 2009 at 12:08 PM, John Snydersjjsnyd...@rcn.com
wrote:
I would like to add my opinion.
...
I do not think individual callbacks for each status code are a good
idea.
Why?
Do you not use XHR with services where you need to do different things
depending on which 4xx code (for example) you receive back? Or do you
just prefer to organize your branching as a switch/case or if/elseif
within an error callback?
In my current app, fairly different handlers are required for say, 401
than 405 or 404, and embedding the branching within switch/case or
if/elseif is ugly and inflexible. This also happens to be a feature
which would be much simpler and better to implement in the core ajax
code than in a plugin.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
On Mon, Sep 7, 2009 at 8:19 PM, John Snydersjjsnyd...@rcn.com wrote: On Sep 7, 6:24 pm, Nathan Bubna nbu...@gmail.com wrote: On Mon, Sep 7, 2009 at 12:08 PM, John Snydersjjsnyd...@rcn.com wrote: I would like to add my opinion. ... I do not think individual callbacks for each status code are a good idea. Why? In my apps the processing done for different status codes is mostly common. So it would be easier for me to just add a little branching as needed. But if I understand what is proposed the status code handler functions are optional and only called if defined. You can still use success and error if you like. So they wouldn't get in my way - it just doesn't seem worth it to me. yeah, i definitely do NOT advocate getting rid of the success and error buckets for status code. the per-statusCode callbacks would be totally optional for those to whom it is very worth it, like me! :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
But following that argumentation a 204 would always be an error since any request expects something (XML by default), no? --Klaus On 23 Jul., 03:35, Dave Methvin dave.meth...@gmail.com wrote: If the request said it wanted json, but it didn't get json, then it's an error in my book. Maybe you could turn a 204 into an empty object but I have a feeling that would be a surprising success case for most json requests. Perhaps, a solution would be to have the option of defining callbacks per status code. You could do that yourself with the existing complete handler, since it is passed the xmlhttp object. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
But following that argumentation a 204 would always be an error since any request expects something (XML by default), no? Well, yeah I guess, except the situation where you were asking for html or text and it could be returned as an empty string on a 204. I want to define error and success in terms of whether it successfully delivered the dataType requested, not the underlying http status code that delivered it. For example, let's say I request dataType:json and the server returns 200 but content that is not valid json. Somehow, $.ajax needs to let me know about that. If it fires the success handler, what should the json argument be? If it's an empty object or null, it doesn't capture the fact there was an error. I won't have any indication that there was a problem unless I try re-parsing the responseText myself. In the 204+json case you could certainly pass a null or empty object to the success handler instead of firing the error handler, although I'd prefer to have it fire an error. Alternate interpretations can always be dealt with by using complete instead of error/success so this seems like an issue of picking the interpretation with the least surprise. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
For what it's worth, `undefined` is an illegal JSON value. You could
pass undefined rather than null or an empty object because json ===
undefined would mean that the json failed since `undefined` is not a
legal json value like `null` and `{}` are.
On Jul 23, 6:33 am, Dave Methvin dave.meth...@gmail.com wrote:
But following that argumentation a 204 would always be an error
since any request expects something (XML by default), no?
Well, yeah I guess, except the situation where you were asking for
html or text and it could be returned as an empty string on a 204. I
want to define error and success in terms of whether it
successfully delivered the dataType requested, not the underlying http
status code that delivered it.
For example, let's say I request dataType:jsonand the server returns
200 but content that is not validjson. Somehow, $.ajax needs to let
me know about that. If it fires the success handler, what should
thejsonargument be? If it's an empty object or null, it doesn't capture
the fact there was an error. I won't have any indication that there
was a problem unless I try re-parsing the responseText myself.
In the 204+jsoncase you could certainly pass a null or empty object
to the success handler instead of firing the error handler, although
I'd prefer to have it fire an error. Alternate interpretations can
always be dealt with by using complete instead of error/success so
this seems like an issue of picking the interpretation with the least
surprise.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
I really, really like what you did here, Nathan. Behavior of $.ajax could
be: option[response.code] ? option[response.code](infos) : error(infos)
So basically, any response code that is not 200 is considered an error BUT
you can specify a specific error callback per type of response. Would that
be really difficult to implement?
2009/7/23 Nathan Bubna nbu...@gmail.com
On Wed, Jul 22, 2009 at 4:42 PM, Justinvhjusti...@gmail.com wrote:
Heh, well...
If we define a successful response as one defined by HTTP/1.1
standards, then any 2xx/3xx based response should be considered
successful. However, I can see that if you are interacting with a
layer such as $.ajax() that specified an expected dataType as a return
that it should reasonably error to some degree.
It is definitely a tangential issue - And is most likely apparent to
any RESTful applications that would rely on status codes to manipulate
client-side interaction.
agreed.
Perhaps, a solution would be to have the option of defining callbacks
per status code.
E.g. $.ajax(..., {
'onStatusCode':
{ '200': {
'dataType': 'json',
'success': function(data) { },
'error': function(data) { }
}
'204': {
'success': function () {
}
}
}
}
i've got something like this in my rest plugin
(http://plugins.jquery.com/project/rest). it's still a young plugin,
but it's already made using jQuery ajax with REST services much, much
easier. it would look something like this for a delete call:
$.Delete('/groups/@me/foo', {
success: function(data) { //do stuff },
204: 'success' // or a function of its own
});
since you seem to be working in the same space, i'd love your feedback
on the plugin, if you've got the time.
- Or something that degree that would allow a 'lower-level' of
interaction with how $.ajax() would handle responses.
On Jul 22, 4:26 pm, John Resig jere...@gmail.com wrote:
I guess that's a tangential issue, not really related to JSON - if a
server
returns a 204 (with no content) should we call success with a null or
undefined data argument?
At the moment I think that's far more likely that when you do a request,
and
you're expecting something (JSON, XML, etc.) and you don't get it (204
or
not), that it should not count as a success. I'd be willing to tweak the
docs to represent that. Of course, I'm willing to be convinced
otherwise.
--John
On Wed, Jul 22, 2009 at 7:10 PM, Justinvh justi...@gmail.com wrote:
There is a parsererror, but the way the error callback is described
seems misleading. What if on a 200 response you returned JSON - But a
204, being that the response code is 'NO CONTENT', would not have JSON
in it. Should it still error?
Shouldn't the desired effect be to ignore the data inside, or is this
logic that should be handled as a case in dataFilter?
On Jul 22, 3:17 pm, John Resig jere...@gmail.com wrote:
What's the error message that you are receiving? Reading through the
code
I'd imagine that you would receive a 'parsererror', which seems
appropriate.
--John
On Wed, Jul 22, 2009 at 3:30 PM, Justinvh justi...@gmail.com
wrote:
Can someone explain me the reasoning that if a dataType is
specified
as JSON and the response code is say a 204 (NO CONTENT), that it
would
error. The way it looks, the code is expecting JSON back, but
since
there is no JSON, it fails.
The documentation however says that error is A function to be
called
if the request fails. - Which makes me think that the actual
request
fails, not that the data parsed failed.
Maybe it's me, but it seems a bit confusing.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
On Thu, Jul 23, 2009 at 3:57 PM, Julian Aubourgaubourg.jul...@gmail.com wrote:
I really, really like what you did here, Nathan.
thanks.
Behavior of $.ajax could
be: option[response.code] ? option[response.code](infos) : error(infos)
So basically, any response code that is not 200 is considered an error BUT
you can specify a specific error callback per type of response. Would that
be really difficult to implement?
actually, i think any status (=200 300) || 304 is considered
successful. 204 is really only an error for dataType:json for now.
this is one of the reasons why i handle json processing myself in my
Rest plugin. when calling the plugin's functions, 204 is successful
and null is passed for the data.
as for supporting the status code specific handlers, i imagine both
the internal success and handleError functions would have to check for
a status code specific handler before calling the provided 'success'
or 'error' ones. i can't imagine why that would be difficult from my
cursory glance over the jQuery code. both have access to the options
and the xhr, so it should be a very simple change. though, i'm not
set up to hack on jQuery itself yet, so i can't make a proper patch at
the moment.
2009/7/23 Nathan Bubna nbu...@gmail.com
On Wed, Jul 22, 2009 at 4:42 PM, Justinvhjusti...@gmail.com wrote:
Heh, well...
If we define a successful response as one defined by HTTP/1.1
standards, then any 2xx/3xx based response should be considered
successful. However, I can see that if you are interacting with a
layer such as $.ajax() that specified an expected dataType as a return
that it should reasonably error to some degree.
It is definitely a tangential issue - And is most likely apparent to
any RESTful applications that would rely on status codes to manipulate
client-side interaction.
agreed.
Perhaps, a solution would be to have the option of defining callbacks
per status code.
E.g. $.ajax(..., {
'onStatusCode':
{ '200': {
'dataType': 'json',
'success': function(data) { },
'error': function(data) { }
}
'204': {
'success': function () {
}
}
}
}
i've got something like this in my rest plugin
(http://plugins.jquery.com/project/rest). it's still a young plugin,
but it's already made using jQuery ajax with REST services much, much
easier. it would look something like this for a delete call:
$.Delete('/groups/@me/foo', {
success: function(data) { //do stuff },
204: 'success' // or a function of its own
});
since you seem to be working in the same space, i'd love your feedback
on the plugin, if you've got the time.
- Or something that degree that would allow a 'lower-level' of
interaction with how $.ajax() would handle responses.
On Jul 22, 4:26 pm, John Resig jere...@gmail.com wrote:
I guess that's a tangential issue, not really related to JSON - if a
server
returns a 204 (with no content) should we call success with a null or
undefined data argument?
At the moment I think that's far more likely that when you do a
request, and
you're expecting something (JSON, XML, etc.) and you don't get it (204
or
not), that it should not count as a success. I'd be willing to tweak
the
docs to represent that. Of course, I'm willing to be convinced
otherwise.
--John
On Wed, Jul 22, 2009 at 7:10 PM, Justinvh justi...@gmail.com wrote:
There is a parsererror, but the way the error callback is described
seems misleading. What if on a 200 response you returned JSON - But a
204, being that the response code is 'NO CONTENT', would not have
JSON
in it. Should it still error?
Shouldn't the desired effect be to ignore the data inside, or is this
logic that should be handled as a case in dataFilter?
On Jul 22, 3:17 pm, John Resig jere...@gmail.com wrote:
What's the error message that you are receiving? Reading through
the code
I'd imagine that you would receive a 'parsererror', which seems
appropriate.
--John
On Wed, Jul 22, 2009 at 3:30 PM, Justinvh justi...@gmail.com
wrote:
Can someone explain me the reasoning that if a dataType is
specified
as JSON and the response code is say a 204 (NO CONTENT), that it
would
error. The way it looks, the code is expecting JSON back, but
since
there is no JSON, it fails.
The documentation however says that error is A function to be
called
if the request fails. - Which makes me think that the actual
request
fails, not that the data parsed failed.
Maybe it's me, but it seems a bit confusing.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
On Thu, Jul 23, 2009 at 5:06 PM, Nathan Bubnanbu...@gmail.com wrote:
On Thu, Jul 23, 2009 at 3:57 PM, Julian Aubourgaubourg.jul...@gmail.com
wrote:
I really, really like what you did here, Nathan.
thanks.
Behavior of $.ajax could
be: option[response.code] ? option[response.code](infos) : error(infos)
So basically, any response code that is not 200 is considered an error BUT
you can specify a specific error callback per type of response. Would that
be really difficult to implement?
actually, i think any status (=200 300) || 304 is considered
successful. 204 is really only an error for dataType:json for now.
this is one of the reasons why i handle json processing myself in my
Rest plugin. when calling the plugin's functions, 204 is successful
and null is passed for the data.
as for supporting the status code specific handlers, i imagine both
the internal success and handleError functions would have to check for
a status code specific handler before calling the provided 'success'
or 'error' ones. i can't imagine why that would be difficult from my
cursory glance over the jQuery code. both have access to the options
and the xhr, so it should be a very simple change. though, i'm not
set up to hack on jQuery itself yet, so i can't make a proper patch at
the moment.
hmm. i just realized that while this would be a handy addition to
jQuery, it would make it very difficult for my plugin to wrap behavior
around ajax callbacks. it's not hard to watch the options for
'success' and 'error'; watching for those and all the possible status
codes would be unpleasant. if such a feature were added, it'd be
nice to also have an extension hook added for before the winning
callback is executed that would give me a chance to identify the
status code and wrap the callback for it, before it was executed.
perhaps named 'ready' that was always called before the winning
callback in the same way 'complete' is always called afterward? it
would probably just need the xhr as an arg. honestly, that would be
very handy regardless of whether support for status code specific
callbacks was added or not.
2009/7/23 Nathan Bubna nbu...@gmail.com
On Wed, Jul 22, 2009 at 4:42 PM, Justinvhjusti...@gmail.com wrote:
Heh, well...
If we define a successful response as one defined by HTTP/1.1
standards, then any 2xx/3xx based response should be considered
successful. However, I can see that if you are interacting with a
layer such as $.ajax() that specified an expected dataType as a return
that it should reasonably error to some degree.
It is definitely a tangential issue - And is most likely apparent to
any RESTful applications that would rely on status codes to manipulate
client-side interaction.
agreed.
Perhaps, a solution would be to have the option of defining callbacks
per status code.
E.g. $.ajax(..., {
'onStatusCode':
{ '200': {
'dataType': 'json',
'success': function(data) { },
'error': function(data) { }
}
'204': {
'success': function () {
}
}
}
}
i've got something like this in my rest plugin
(http://plugins.jquery.com/project/rest). it's still a young plugin,
but it's already made using jQuery ajax with REST services much, much
easier. it would look something like this for a delete call:
$.Delete('/groups/@me/foo', {
success: function(data) { //do stuff },
204: 'success' // or a function of its own
});
since you seem to be working in the same space, i'd love your feedback
on the plugin, if you've got the time.
- Or something that degree that would allow a 'lower-level' of
interaction with how $.ajax() would handle responses.
On Jul 22, 4:26 pm, John Resig jere...@gmail.com wrote:
I guess that's a tangential issue, not really related to JSON - if a
server
returns a 204 (with no content) should we call success with a null or
undefined data argument?
At the moment I think that's far more likely that when you do a
request, and
you're expecting something (JSON, XML, etc.) and you don't get it (204
or
not), that it should not count as a success. I'd be willing to tweak
the
docs to represent that. Of course, I'm willing to be convinced
otherwise.
--John
On Wed, Jul 22, 2009 at 7:10 PM, Justinvh justi...@gmail.com wrote:
There is a parsererror, but the way the error callback is described
seems misleading. What if on a 200 response you returned JSON - But a
204, being that the response code is 'NO CONTENT', would not have
JSON
in it. Should it still error?
Shouldn't the desired effect be to ignore the data inside, or is this
logic that should be handled as a case in dataFilter?
On Jul 22, 3:17 pm, John Resig jere...@gmail.com wrote:
What's the error message that you are receiving? Reading through
the code
I'd imagine that you would receive a
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
Ideally, this is what I would want:
{
200: function (xhr) { .. do stuff .. },
204: function (xhr) { .. do stuff .. }
}
When a response of 200/204 is called, the error/success logic is
tossed and is instead handled specifically by the 200/204 callbacks.
This would allow a greater granularity and control over what can be
done with whatever data comes back.
I suppose this would also require some sort of generic $.ajax.parse
(data_type, xhr) function that consumes a dataType as like-specified
in $.ajax() and the xhr object. It would return expected results or
throw errors or whatever the jquery-ism in this case would be.
On Jul 23, 5:24 pm, Nathan Bubna nbu...@gmail.com wrote:
granularity
On Thu, Jul 23, 2009 at 5:06 PM, Nathan Bubnanbu...@gmail.com wrote:
On Thu, Jul 23, 2009 at 3:57 PM, Julian Aubourgaubourg.jul...@gmail.com
wrote:
I really, really like what you did here, Nathan.
thanks.
Behavior of $.ajax could
be: option[response.code] ? option[response.code](infos) : error(infos)
So basically, any response code that is not 200 is considered an error BUT
you can specify a specific error callback per type of response. Would that
be really difficult to implement?
actually, i think any status (=200 300) || 304 is considered
successful. 204 is really only an error for dataType:json for now.
this is one of the reasons why i handle json processing myself in my
Rest plugin. when calling the plugin's functions, 204 is successful
and null is passed for the data.
as for supporting the status code specific handlers, i imagine both
the internal success and handleError functions would have to check for
a status code specific handler before calling the provided 'success'
or 'error' ones. i can't imagine why that would be difficult from my
cursory glance over the jQuery code. both have access to the options
and the xhr, so it should be a very simple change. though, i'm not
set up to hack on jQuery itself yet, so i can't make a proper patch at
the moment.
hmm. i just realized that while this would be a handy addition to
jQuery, it would make it very difficult for my plugin to wrap behavior
around ajax callbacks. it's not hard to watch the options for
'success' and 'error'; watching for those and all the possible status
codes would be unpleasant. if such a feature were added, it'd be
nice to also have an extension hook added for before the winning
callback is executed that would give me a chance to identify the
status code and wrap the callback for it, before it was executed.
perhaps named 'ready' that was always called before the winning
callback in the same way 'complete' is always called afterward? it
would probably just need the xhr as an arg. honestly, that would be
very handy regardless of whether support for status code specific
callbacks was added or not.
2009/7/23 Nathan Bubna nbu...@gmail.com
On Wed, Jul 22, 2009 at 4:42 PM, Justinvhjusti...@gmail.com wrote:
Heh, well...
If we define a successful response as one defined by HTTP/1.1
standards, then any 2xx/3xx based response should be considered
successful. However, I can see that if you are interacting with a
layer such as $.ajax() that specified an expected dataType as a return
that it should reasonably error to some degree.
It is definitely a tangential issue - And is most likely apparent to
any RESTful applications that would rely on status codes to manipulate
client-side interaction.
agreed.
Perhaps, a solution would be to have the option of defining callbacks
per status code.
E.g. $.ajax(..., {
'onStatusCode':
{ '200': {
'dataType': 'json',
'success': function(data) { },
'error': function(data) { }
}
'204': {
'success': function () {
}
}
}
}
i've got something like this in my rest plugin
(http://plugins.jquery.com/project/rest). it's still a young plugin,
but it's already made using jQuery ajax with REST services much, much
easier. it would look something like this for a delete call:
$.Delete('/groups/@me/foo', {
success: function(data) { //do stuff },
204: 'success' // or a function of its own
});
since you seem to be working in the same space, i'd love your feedback
on the plugin, if you've got the time.
- Or something that degree that would allow a 'lower-level' of
interaction with how $.ajax() would handle responses.
On Jul 22, 4:26 pm, John Resig jere...@gmail.com wrote:
I guess that's a tangential issue, not really related to JSON - if a
server
returns a 204 (with no content) should we call success with a null or
undefined data argument?
At the moment I think that's far more likely that when you do a
request, and
you're expecting something (JSON, XML, etc.) and you don't get it (204
or
not), that it should not
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
Ignore my previous laziness, i went ahead filed a feature request
along with a suggested patch:
http://dev.jquery.com/ticket/4964
Adds support for a ready callback and for status code specific
callbacks to supersede any generic 'success' or 'error' ones.
On Thu, Jul 23, 2009 at 5:24 PM, Nathan Bubnanbu...@gmail.com wrote:
On Thu, Jul 23, 2009 at 5:06 PM, Nathan Bubnanbu...@gmail.com wrote:
On Thu, Jul 23, 2009 at 3:57 PM, Julian Aubourgaubourg.jul...@gmail.com
wrote:
I really, really like what you did here, Nathan.
thanks.
Behavior of $.ajax could
be: option[response.code] ? option[response.code](infos) : error(infos)
So basically, any response code that is not 200 is considered an error BUT
you can specify a specific error callback per type of response. Would that
be really difficult to implement?
actually, i think any status (=200 300) || 304 is considered
successful. 204 is really only an error for dataType:json for now.
this is one of the reasons why i handle json processing myself in my
Rest plugin. when calling the plugin's functions, 204 is successful
and null is passed for the data.
as for supporting the status code specific handlers, i imagine both
the internal success and handleError functions would have to check for
a status code specific handler before calling the provided 'success'
or 'error' ones. i can't imagine why that would be difficult from my
cursory glance over the jQuery code. both have access to the options
and the xhr, so it should be a very simple change. though, i'm not
set up to hack on jQuery itself yet, so i can't make a proper patch at
the moment.
hmm. i just realized that while this would be a handy addition to
jQuery, it would make it very difficult for my plugin to wrap behavior
around ajax callbacks. it's not hard to watch the options for
'success' and 'error'; watching for those and all the possible status
codes would be unpleasant. if such a feature were added, it'd be
nice to also have an extension hook added for before the winning
callback is executed that would give me a chance to identify the
status code and wrap the callback for it, before it was executed.
perhaps named 'ready' that was always called before the winning
callback in the same way 'complete' is always called afterward? it
would probably just need the xhr as an arg. honestly, that would be
very handy regardless of whether support for status code specific
callbacks was added or not.
2009/7/23 Nathan Bubna nbu...@gmail.com
On Wed, Jul 22, 2009 at 4:42 PM, Justinvhjusti...@gmail.com wrote:
Heh, well...
If we define a successful response as one defined by HTTP/1.1
standards, then any 2xx/3xx based response should be considered
successful. However, I can see that if you are interacting with a
layer such as $.ajax() that specified an expected dataType as a return
that it should reasonably error to some degree.
It is definitely a tangential issue - And is most likely apparent to
any RESTful applications that would rely on status codes to manipulate
client-side interaction.
agreed.
Perhaps, a solution would be to have the option of defining callbacks
per status code.
E.g. $.ajax(..., {
'onStatusCode':
{ '200': {
'dataType': 'json',
'success': function(data) { },
'error': function(data) { }
}
'204': {
'success': function () {
}
}
}
}
i've got something like this in my rest plugin
(http://plugins.jquery.com/project/rest). it's still a young plugin,
but it's already made using jQuery ajax with REST services much, much
easier. it would look something like this for a delete call:
$.Delete('/groups/@me/foo', {
success: function(data) { //do stuff },
204: 'success' // or a function of its own
});
since you seem to be working in the same space, i'd love your feedback
on the plugin, if you've got the time.
- Or something that degree that would allow a 'lower-level' of
interaction with how $.ajax() would handle responses.
On Jul 22, 4:26 pm, John Resig jere...@gmail.com wrote:
I guess that's a tangential issue, not really related to JSON - if a
server
returns a 204 (with no content) should we call success with a null or
undefined data argument?
At the moment I think that's far more likely that when you do a
request, and
you're expecting something (JSON, XML, etc.) and you don't get it (204
or
not), that it should not count as a success. I'd be willing to tweak
the
docs to represent that. Of course, I'm willing to be convinced
otherwise.
--John
On Wed, Jul 22, 2009 at 7:10 PM, Justinvh justi...@gmail.com wrote:
There is a parsererror, but the way the error callback is described
seems misleading. What if on a 200 response you returned JSON - But a
204, being that the response code is 'NO CONTENT', would not have
JSON
in
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
What's the error message that you are receiving? Reading through the code I'd imagine that you would receive a 'parsererror', which seems appropriate. --John On Wed, Jul 22, 2009 at 3:30 PM, Justinvh justi...@gmail.com wrote: Can someone explain me the reasoning that if a dataType is specified as JSON and the response code is say a 204 (NO CONTENT), that it would error. The way it looks, the code is expecting JSON back, but since there is no JSON, it fails. The documentation however says that error is A function to be called if the request fails. - Which makes me think that the actual request fails, not that the data parsed failed. Maybe it's me, but it seems a bit confusing. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
There is a parsererror, but the way the error callback is described seems misleading. What if on a 200 response you returned JSON - But a 204, being that the response code is 'NO CONTENT', would not have JSON in it. Should it still error? Shouldn't the desired effect be to ignore the data inside, or is this logic that should be handled as a case in dataFilter? On Jul 22, 3:17 pm, John Resig jere...@gmail.com wrote: What's the error message that you are receiving? Reading through the code I'd imagine that you would receive a 'parsererror', which seems appropriate. --John On Wed, Jul 22, 2009 at 3:30 PM, Justinvh justi...@gmail.com wrote: Can someone explain me the reasoning that if a dataType is specified as JSON and the response code is say a 204 (NO CONTENT), that it would error. The way it looks, the code is expecting JSON back, but since there is no JSON, it fails. The documentation however says that error is A function to be called if the request fails. - Which makes me think that the actual request fails, not that the data parsed failed. Maybe it's me, but it seems a bit confusing. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
Heh, well...
If we define a successful response as one defined by HTTP/1.1
standards, then any 2xx/3xx based response should be considered
successful. However, I can see that if you are interacting with a
layer such as $.ajax() that specified an expected dataType as a return
that it should reasonably error to some degree.
It is definitely a tangential issue - And is most likely apparent to
any RESTful applications that would rely on status codes to manipulate
client-side interaction.
Perhaps, a solution would be to have the option of defining callbacks
per status code.
E.g. $.ajax(..., {
'onStatusCode':
{ '200': {
'dataType': 'json',
'success': function(data) { },
'error': function(data) { }
}
'204': {
'success': function () {
}
}
}
}
- Or something that degree that would allow a 'lower-level' of
interaction with how $.ajax() would handle responses.
On Jul 22, 4:26 pm, John Resig jere...@gmail.com wrote:
I guess that's a tangential issue, not really related to JSON - if a server
returns a 204 (with no content) should we call success with a null or
undefined data argument?
At the moment I think that's far more likely that when you do a request, and
you're expecting something (JSON, XML, etc.) and you don't get it (204 or
not), that it should not count as a success. I'd be willing to tweak the
docs to represent that. Of course, I'm willing to be convinced otherwise.
--John
On Wed, Jul 22, 2009 at 7:10 PM, Justinvh justi...@gmail.com wrote:
There is a parsererror, but the way the error callback is described
seems misleading. What if on a 200 response you returned JSON - But a
204, being that the response code is 'NO CONTENT', would not have JSON
in it. Should it still error?
Shouldn't the desired effect be to ignore the data inside, or is this
logic that should be handled as a case in dataFilter?
On Jul 22, 3:17 pm, John Resig jere...@gmail.com wrote:
What's the error message that you are receiving? Reading through the code
I'd imagine that you would receive a 'parsererror', which seems
appropriate.
--John
On Wed, Jul 22, 2009 at 3:30 PM, Justinvh justi...@gmail.com wrote:
Can someone explain me the reasoning that if a dataType is specified
as JSON and the response code is say a 204 (NO CONTENT), that it would
error. The way it looks, the code is expecting JSON back, but since
there is no JSON, it fails.
The documentation however says that error is A function to be called
if the request fails. - Which makes me think that the actual request
fails, not that the data parsed failed.
Maybe it's me, but it seems a bit confusing.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
If the request said it wanted json, but it didn't get json, then it's an error in my book. Maybe you could turn a 204 into an empty object but I have a feeling that would be a surprising success case for most json requests. Perhaps, a solution would be to have the option of defining callbacks per status code. You could do that yourself with the existing complete handler, since it is passed the xmlhttp object. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
On Wed, Jul 22, 2009 at 4:42 PM, Justinvhjusti...@gmail.com wrote:
Heh, well...
If we define a successful response as one defined by HTTP/1.1
standards, then any 2xx/3xx based response should be considered
successful. However, I can see that if you are interacting with a
layer such as $.ajax() that specified an expected dataType as a return
that it should reasonably error to some degree.
It is definitely a tangential issue - And is most likely apparent to
any RESTful applications that would rely on status codes to manipulate
client-side interaction.
agreed.
Perhaps, a solution would be to have the option of defining callbacks
per status code.
E.g. $.ajax(..., {
'onStatusCode':
{ '200': {
'dataType': 'json',
'success': function(data) { },
'error': function(data) { }
}
'204': {
'success': function () {
}
}
}
}
i've got something like this in my rest plugin
(http://plugins.jquery.com/project/rest). it's still a young plugin,
but it's already made using jQuery ajax with REST services much, much
easier. it would look something like this for a delete call:
$.Delete('/groups/@me/foo', {
success: function(data) { //do stuff },
204: 'success' // or a function of its own
});
since you seem to be working in the same space, i'd love your feedback
on the plugin, if you've got the time.
- Or something that degree that would allow a 'lower-level' of
interaction with how $.ajax() would handle responses.
On Jul 22, 4:26 pm, John Resig jere...@gmail.com wrote:
I guess that's a tangential issue, not really related to JSON - if a server
returns a 204 (with no content) should we call success with a null or
undefined data argument?
At the moment I think that's far more likely that when you do a request, and
you're expecting something (JSON, XML, etc.) and you don't get it (204 or
not), that it should not count as a success. I'd be willing to tweak the
docs to represent that. Of course, I'm willing to be convinced otherwise.
--John
On Wed, Jul 22, 2009 at 7:10 PM, Justinvh justi...@gmail.com wrote:
There is a parsererror, but the way the error callback is described
seems misleading. What if on a 200 response you returned JSON - But a
204, being that the response code is 'NO CONTENT', would not have JSON
in it. Should it still error?
Shouldn't the desired effect be to ignore the data inside, or is this
logic that should be handled as a case in dataFilter?
On Jul 22, 3:17 pm, John Resig jere...@gmail.com wrote:
What's the error message that you are receiving? Reading through the code
I'd imagine that you would receive a 'parsererror', which seems
appropriate.
--John
On Wed, Jul 22, 2009 at 3:30 PM, Justinvh justi...@gmail.com wrote:
Can someone explain me the reasoning that if a dataType is specified
as JSON and the response code is say a 204 (NO CONTENT), that it would
error. The way it looks, the code is expecting JSON back, but since
there is no JSON, it fails.
The documentation however says that error is A function to be called
if the request fails. - Which makes me think that the actual request
fails, not that the data parsed failed.
Maybe it's me, but it seems a bit confusing.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
