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 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
-~----------~----~----~----~------~----~------~--~---
