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 Bubna<nbu...@gmail.com> wrote: > On Thu, Jul 23, 2009 at 5:06 PM, Nathan Bubna<nbu...@gmail.com> wrote: >> On Thu, Jul 23, 2009 at 3:57 PM, Julian Aubourg<aubourg.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, Justinvh<justi...@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 -~----------~----~----~----~------~----~------~--~---
