Calling callback in $.post & $.get on error

[Mr Speaker]

The $.post and $.get are really handy, but seem limited in their use
for serious work because you can't tell if they fail (can you? I mean,
besides the global error handler?).

I couldn't find any discussion on this, it would be useful if you
could just call the same callback method for either success or error
and let the user play with the result:

post: function( url, data, callback, type ) {
        ...
        return jQuery.ajax({
                type: "POST",
                url: url,
                data: data,
                success: callback,
                error: callback,  <-- same function
                dataType: type
        });

This would be especially useful for $.post where it's usually pretty
important that you know that an update has occurred. In the
documentation the callback code has this comment:
// NOTE: Apparently, only "success" is returned when you make
// an Ajax call in this way. Other errors silently fail.

So I guess there is a reason for not doing this... it would break
existing code for people who just checked for ANY return value, and I
suppose it complicates the simple $.post function a little - but it
would give these helper functions more "real world" uses.

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[John Resig]

Making that change as-is would definitely seem to break code. Really
the get and post methods are meant to be simple cases, everything else
should be tackled with the ajax method.

--John

On Sunday, November 8, 2009, Mr Speaker <mrspeaker@...> wrote:

> The $.post and $.get are really handy, but seem limited in their use
> for serious work because you can't tell if they fail (can you? I mean,
> besides the global error handler?).
>
> I couldn't find any discussion on this, it would be useful if you
> could just call the same callback method for either success or error
> and let the user play with the result:
>
> post: function( url, data, callback, type ) {
>         ...
>         return jQuery.ajax({
>                 type: "POST",
>                 url: url,
>                 data: data,
>                 success: callback,
>                 error: callback,  <-- same function
>                 dataType: type
>         });
>
> This would be especially useful for $.post where it's usually pretty
> important that you know that an update has occurred. In the
> documentation the callback code has this comment:
> // NOTE: Apparently, only "success" is returned when you make
> // an Ajax call in this way. Other errors silently fail.
>
> So I guess there is a reason for not doing this... it would break
> existing code for people who just checked for ANY return value, and I
> suppose it complicates the simple $.post function a little - but it
> would give these helper functions more "real world" uses.
>
> --
>
> 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@....
> To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
> For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
>
>
>

--
--John

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[jaubourg]

As simple as they should be I always wondered why $.get (and $.getJSON) and $.post don't have the option to provide an error callback as a third parameter. I mean, simple cases don't protect from temporary connection and/or server shutdowns, do they? With the current success callback only design, it gives library users the illusion nothing can go wrong with $.get and $.put.

2009/11/8 John Resig <jeresig@...>

Making that change as-is would definitely seem to break code. Really
the get and post methods are meant to be simple cases, everything else
should be tackled with the ajax method.

--John

On Sunday, November 8, 2009, Mr Speaker <mrspeaker@...> wrote:
> The $.post and $.get are really handy, but seem limited in their use
> for serious work because you can't tell if they fail (can you? I mean,
> besides the global error handler?).
>
> I couldn't find any discussion on this, it would be useful if you
> could just call the same callback method for either success or error
> and let the user play with the result:
>
> post: function( url, data, callback, type ) {
>         ...
>         return jQuery.ajax({
>                 type: "POST",
>                 url: url,
>                 data: data,
>                 success: callback,
>                 error: callback,  <-- same function
>                 dataType: type
>         });
>
> This would be especially useful for $.post where it's usually pretty
> important that you know that an update has occurred. In the
> documentation the callback code has this comment:
> // NOTE: Apparently, only "success" is returned when you make
> // an Ajax call in this way. Other errors silently fail.
>
> So I guess there is a reason for not doing this... it would break
> existing code for people who just checked for ANY return value, and I
> suppose it complicates the simple $.post function a little - but it
> would give these helper functions more "real world" uses.
>
> --
>
> 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@....
> To unsubscribe from this group, send email to jquery-dev%2Bunsubscribe@....
> For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
>
>
>

--
--John

--

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@....
To unsubscribe from this group, send email to jquery-dev%2Bunsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[John Resig]

I've thought about your post some more and I think this might actually
be ok. Considering that right now the only callback that is fired is
the success callback we can safely assume that people who are using
this method don't actually care about the error state - thus if we
pass in the normal error callback the page will still break (albeit in
a different manner).

Thus if you wanted to make proper use of the $.get or $.post with the
dual-callback functionality you would have to do:

$.get("someurl", function(data){
  if ( typeof data === "string" ) {
    // got results
  } else {
    // got error
  }
});

Another option could be a modified error callback and actually have it
work like this:

$.get("someurl", function(data, errorMessage){
  if ( data ) {
    // got results
  } else {
    // got error
    alert( errorMessage );
  }
});

Thoughts on this?

--John



On Sun, Nov 8, 2009 at 12:29 PM, Mr Speaker <mrspeaker@...> wrote:

> The $.post and $.get are really handy, but seem limited in their use
> for serious work because you can't tell if they fail (can you? I mean,
> besides the global error handler?).
>
> I couldn't find any discussion on this, it would be useful if you
> could just call the same callback method for either success or error
> and let the user play with the result:
>
> post: function( url, data, callback, type ) {
>        ...
>        return jQuery.ajax({
>                type: "POST",
>                url: url,
>                data: data,
>                success: callback,
>                error: callback,  <-- same function
>                dataType: type
>        });
>
> This would be especially useful for $.post where it's usually pretty
> important that you know that an update has occurred. In the
> documentation the callback code has this comment:
> // NOTE: Apparently, only "success" is returned when you make
> // an Ajax call in this way. Other errors silently fail.
>
> So I guess there is a reason for not doing this... it would break
> existing code for people who just checked for ANY return value, and I
> suppose it complicates the simple $.post function a little - but it
> would give these helper functions more "real world" uses.
>
> --
>
> 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@....
> To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
> For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
>
>
>

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[Scott Sauyet-2]

> Another option could be a modified error callback and actually have it
> work like this:
>
> $.get("someurl", function(data, errorMessage){
>  if ( data ) {
>    // got results
>  } else {
>    // got error
>    alert( errorMessage );
>  }
> });
>
> Thoughts on this?

This one looks cleaner to me; and it certainly seems nicer than
expecting the user to do "if ( typeof data === 'string' )"  Nothing
would be be passed as a second parameter on success, right?  I like
it.

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[jaubourg]

Wouldn't it still break some scripts that actually expect the data never to be undefined?

Why not the following:

$.get("someurl", function(data) {
   // got results
 }, function(errorMessage) {
   // got error
 });

That way, actual scripts behave as usual and new ones can provide an error callback.

Thoughts?

2009/11/9 John Resig <jeresig@...>

I've thought about your post some more and I think this might actually
be ok. Considering that right now the only callback that is fired is
the success callback we can safely assume that people who are using
this method don't actually care about the error state - thus if we
pass in the normal error callback the page will still break (albeit in
a different manner).

Thus if you wanted to make proper use of the $.get or $.post with the
dual-callback functionality you would have to do:

$.get("someurl", function(data){
 if ( typeof data === "string" ) {
   // got results
 } else {
   // got error
 }
});

Another option could be a modified error callback and actually have it
work like this:

$.get("someurl", function(data, errorMessage){
 if ( data ) {
   // got results
 } else {
   // got error
   alert( errorMessage );
 }
});

Thoughts on this?

--John

On Sun, Nov 8, 2009 at 12:29 PM, Mr Speaker <mrspeaker@...> wrote:
> The $.post and $.get are really handy, but seem limited in their use
> for serious work because you can't tell if they fail (can you? I mean,
> besides the global error handler?).
>
> I couldn't find any discussion on this, it would be useful if you
> could just call the same callback method for either success or error
> and let the user play with the result:
>
> post: function( url, data, callback, type ) {
>        ...
>        return jQuery.ajax({
>                type: "POST",
>                url: url,
>                data: data,
>                success: callback,
>                error: callback,  <-- same function
>                dataType: type
>        });
>
> This would be especially useful for $.post where it's usually pretty
> important that you know that an update has occurred. In the
> documentation the callback code has this comment:
> // NOTE: Apparently, only "success" is returned when you make
> // an Ajax call in this way. Other errors silently fail.
>
> So I guess there is a reason for not doing this... it would break
> existing code for people who just checked for ANY return value, and I
> suppose it complicates the simple $.post function a little - but it
> would give these helper functions more "real world" uses.
>
> --
>
> 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@....
> To unsubscribe from this group, send email to jquery-dev%2Bunsubscribe@....
> For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
>
>
>

--

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@....
To unsubscribe from this group, send email to jquery-dev%2Bunsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[John Resig]

> Wouldn't it still break some scripts that actually expect the data never to
> be undefined?

As I mentioned before - the application would just break in a
different way. Normally it would break in that the result would never
come in - now it would throw an exception (again, that's assuming that
if they're trying to do something directly with the object - a more
likely result is seeing "null" outputted somewhere).

> Why not the following:
>
> $.get("someurl", function(data) {
>    // got results
>  }, function(errorMessage) {
>    // got error
>  });
>
> That way, actual scripts behave as usual and new ones can provide an error
> callback.
>
> Thoughts?

I'm not a huge fan of this - having dual functions being passed in as
arguments is messy and against the current jQuery conventions. I feel
like if you're passing in so many functions why not just use $.ajax
and be done with it? Especially since $.ajax is so much more explicit
any way.

Either we should find a simple solution (like what I proposed) or do
no change at all.

--John

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[Markw65]

On Nov 9, 7:29 am, John Resig <jere...@...> wrote:
> As I mentioned before - the application would just break in a
> different way. Normally it would break in that the result would never
> come in - now it would throw an exception (again, that's assuming that

I dont think thats true. There are plenty of use cases where not
getting a result is not a problem - and using $.get in any other
situation would be wrong.

eg a status box that updates every minute. If the result doesnt come
back, you dont update the status. Nobody minds, the status is just a
little old.

But getting a null result would (or certainly could) break it.

So I think your statement only applies to incorrect usage of $.get.

Mark

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[jaubourg]

Well, to be honest, I never ever use $.get or $.put (or $.getJSON). The main reason is that there is no error callback which, in my opinion, makes them completely useless in any production environment.

Now I understand the convention being broken argument, but the two callback solution:
- does not break current code, ever,
- does not necessitate jQuery to create a special error callback that will redirect to the dual callback function,
- does not necessitate branching in user code.

I dunno, but for helper functions, I'd be willing to sacrifice some api purity and have them really useful yet backward compatible. But, then again, I never had the responsibility of anything that's became as huge as jQuery, so...

2009/11/9 John Resig <jeresig@...>

> Wouldn't it still break some scripts that actually expect the data never to
> be undefined?

As I mentioned before - the application would just break in a
different way. Normally it would break in that the result would never
come in - now it would throw an exception (again, that's assuming that
if they're trying to do something directly with the object - a more
likely result is seeing "null" outputted somewhere).

> Why not the following:
>
> $.get("someurl", function(data) {
>    // got results
>  }, function(errorMessage) {
>    // got error
>  });
>
> That way, actual scripts behave as usual and new ones can provide an error
> callback.
>
> Thoughts?

I'm not a huge fan of this - having dual functions being passed in as
arguments is messy and against the current jQuery conventions. I feel
like if you're passing in so many functions why not just use $.ajax
and be done with it? Especially since $.ajax is so much more explicit
any way.

Either we should find a simple solution (like what I proposed) or do
no change at all.

--John

--

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@....
To unsubscribe from this group, send email to jquery-dev%2Bunsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[John Resig]

Ok, so I go back to my original statement: "Really the get and post
methods are meant to be simple cases, everything else should be
tackled with the ajax method."

--John



On Mon, Nov 9, 2009 at 4:48 PM, Julian Aubourg <aubourg.julian@...> wrote:

> Well, to be honest, I never ever use $.get or $.put (or $.getJSON). The main
> reason is that there is no error callback which, in my opinion, makes them
> completely useless in any production environment.
>
> Now I understand the convention being broken argument, but the two callback
> solution:
> - does not break current code, ever,
> - does not necessitate jQuery to create a special error callback that will
> redirect to the dual callback function,
> - does not necessitate branching in user code.
>
> I dunno, but for helper functions, I'd be willing to sacrifice some api
> purity and have them really useful yet backward compatible. But, then again,
> I never had the responsibility of anything that's became as huge as jQuery,
> so...
>
> 2009/11/9 John Resig <jeresig@...>
>>
>> > Wouldn't it still break some scripts that actually expect the data never
>> > to
>> > be undefined?
>>
>> As I mentioned before - the application would just break in a
>> different way. Normally it would break in that the result would never
>> come in - now it would throw an exception (again, that's assuming that
>> if they're trying to do something directly with the object - a more
>> likely result is seeing "null" outputted somewhere).
>>
>> > Why not the following:
>> >
>> > $.get("someurl", function(data) {
>> >    // got results
>> >  }, function(errorMessage) {
>> >    // got error
>> >  });
>> >
>> > That way, actual scripts behave as usual and new ones can provide an
>> > error
>> > callback.
>> >
>> > Thoughts?
>>
>> I'm not a huge fan of this - having dual functions being passed in as
>> arguments is messy and against the current jQuery conventions. I feel
>> like if you're passing in so many functions why not just use $.ajax
>> and be done with it? Especially since $.ajax is so much more explicit
>> any way.
>>
>> Either we should find a simple solution (like what I proposed) or do
>> no change at all.
>>
>> --John
>>
>> --
>>
>> 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@....
>> To unsubscribe from this group, send email to
>> jquery-dev+unsubscribe@....
>> For more options, visit this group at
>> http://groups.google.com/group/jquery-dev?hl=en.
>>
>>
>
> --
>
> 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@....
> To unsubscribe from this group, send email to
> jquery-dev+unsubscribe@....
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.
>

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[Karl Swedberg-2]

Couldn't you just use the .ajaxError() method in conjunction with $.get or $.post? That seems to work for me.

http://docs.jquery.com/Ajax/ajaxError#callback

--Karl

On Nov 9, 2009, at 10:48 AM, Julian Aubourg wrote:

Well, to be honest, I never ever use $.get or $.put (or $.getJSON). The main reason is that there is no error callback which, in my opinion, makes them completely useless in any production environment.

Now I understand the convention being broken argument, but the two callback solution:
- does not break current code, ever,
- does not necessitate jQuery to create a special error callback that will redirect to the dual callback function,
- does not necessitate branching in user code.

I dunno, but for helper functions, I'd be willing to sacrifice some api purity and have them really useful yet backward compatible. But, then again, I never had the responsibility of anything that's became as huge as jQuery, so...

2009/11/9 John Resig <jeresig@...>

> Wouldn't it still break some scripts that actually expect the data never to
> be undefined?

As I mentioned before - the application would just break in a
different way. Normally it would break in that the result would never
come in - now it would throw an exception (again, that's assuming that
if they're trying to do something directly with the object - a more
likely result is seeing "null" outputted somewhere).

> Why not the following:
>
> $.get("someurl", function(data) {
>    // got results
>  }, function(errorMessage) {
>    // got error
>  });
>
> That way, actual scripts behave as usual and new ones can provide an error
> callback.
>
> Thoughts?

I'm not a huge fan of this - having dual functions being passed in as
arguments is messy and against the current jQuery conventions. I feel
like if you're passing in so many functions why not just use $.ajax
and be done with it? Especially since $.ajax is so much more explicit
any way.

Either we should find a simple solution (like what I proposed) or do
no change at all.

--John

--

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@....
To unsubscribe from this group, send email to jquery-dev%2Bunsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[jaubourg]

OK and well I guess, but I'll go back to my original statement too then: "simple cases don't protect from temporary connection and/or server shutdowns, do they?". Like I said, I will use $.ajax anyway, but let me re-iterate that simple in design (rather in signature here) does not mean suitable for simple cases. The OP problem is quite clear: for "serious work" (ie: in real world production), error handling is mandatory because no matter how simple the ajax call, error can (and will) occur. I'm afraid the simple cases you're refering to are nothing more than proof of concepts and I personally don't use jQuery to do prototypes but real world web sites.

That being said, the current status of $.get and $.post also pushes developers into ignoring errors altogether which makes for plugins you have to modify (or just plain rewrite) for production use (sadly talking from experience here).

Finally, handling error cases with $.ajaxError in that case is like crushing an egg with a grand piano.

And before anybody jumps at my throat, let me say again that I mean no disrespect: I admire the work you guys put into jQuery and I shudder to imagine how I would develop without this fantastic toolbox but, as of today, $.get and $.post are not "write less, do more", they are "write less, do half the work".

But well, what do I care? I never use them anyway ;)

2009/11/9 John Resig <jeresig@...>

Ok, so I go back to my original statement: "Really the get and post

methods are meant to be simple cases, everything else should be
tackled with the ajax method."

--John

On Mon, Nov 9, 2009 at 4:48 PM, Julian Aubourg <aubourg.julian@...> wrote:
> Well, to be honest, I never ever use $.get or $.put (or $.getJSON). The main
> reason is that there is no error callback which, in my opinion, makes them
> completely useless in any production environment.
>
> Now I understand the convention being broken argument, but the two callback
> solution:
> - does not break current code, ever,
> - does not necessitate jQuery to create a special error callback that will
> redirect to the dual callback function,
> - does not necessitate branching in user code.
>
> I dunno, but for helper functions, I'd be willing to sacrifice some api
> purity and have them really useful yet backward compatible. But, then again,
> I never had the responsibility of anything that's became as huge as jQuery,
> so...
>
> 2009/11/9 John Resig <jeresig@...>
>>
>> > Wouldn't it still break some scripts that actually expect the data never
>> > to
>> > be undefined?
>>
>> As I mentioned before - the application would just break in a
>> different way. Normally it would break in that the result would never
>> come in - now it would throw an exception (again, that's assuming that
>> if they're trying to do something directly with the object - a more
>> likely result is seeing "null" outputted somewhere).
>>
>> > Why not the following:
>> >
>> > $.get("someurl", function(data) {
>> >    // got results
>> >  }, function(errorMessage) {
>> >    // got error
>> >  });
>> >
>> > That way, actual scripts behave as usual and new ones can provide an
>> > error
>> > callback.
>> >
>> > Thoughts?
>>
>> I'm not a huge fan of this - having dual functions being passed in as
>> arguments is messy and against the current jQuery conventions. I feel
>> like if you're passing in so many functions why not just use $.ajax
>> and be done with it? Especially since $.ajax is so much more explicit
>> any way.
>>
>> Either we should find a simple solution (like what I proposed) or do
>> no change at all.
>>
>> --John
>>
>> --
>>
>> 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@....
>> To unsubscribe from this group, send email to
>> jquery-dev%2Bunsubscribe@....
>> For more options, visit this group at
>> http://groups.google.com/group/jquery-dev?hl=en.
>>
>>
>
> --
>
> 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@....
> To unsubscribe from this group, send email to
> jquery-dev%2Bunsubscribe@....
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.
>

--

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@....
To unsubscribe from this group, send email to jquery-dev%2Bunsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[Jason Persampieri-2]

I agree with pretty much everything Julian said.  And while I don't
have a problem with $.get(url, onSuccess, onError), I can see how this
isn't "jQuery-like".

Right now, $.get returns an XmlHttpRequest object.  What if that
object were extended a bit?

$.get(url, callback).error( onError )

Or, heck, go even crazier.... all $.ajax calls return a jQueryAjax
Object (that responds to everything XmlHttpRequest objects do... for
backwards compatibility)... that could lead to

$.get(url).success( callback ).error( callback ).

Interestingly, this would lead to the ability to cleanly request a
resource, then define how you want to handle it later on, even after
it's already come back.

That's at least a *little* more jQuery-like :)

_jason

On Nov 9, 9:49 am, Julian Aubourg <aubourg.jul...@...> wrote:

> OK and well I guess, but I'll go back to my original statement too then:
> "simple cases don't protect from temporary connection and/or server
> shutdowns, do they?". Like I said, I will use $.ajax anyway, but let me
> re-iterate that simple in design (rather in signature here) does not mean
> suitable for simple cases. The OP problem is quite clear: for "serious work"
> (ie: in real world production), error handling is mandatory because no
> matter how simple the ajax call, error can (and will) occur. I'm afraid the
> simple cases you're refering to are nothing more than proof of concepts and
> I personally don't use jQuery to do prototypes but real world web sites.
>
> That being said, the current status of $.get and $.post also pushes
> developers into ignoring errors altogether which makes for plugins you have
> to modify (or just plain rewrite) for production use (sadly talking from
> experience here).
>
> Finally, handling error cases with $.ajaxError in that case is like crushing
> an egg with a grand piano.
>
> And before anybody jumps at my throat, let me say again that I mean no
> disrespect: I admire the work you guys put into jQuery and I shudder to
> imagine how I would develop without this fantastic toolbox but, as of today,
> $.get and $.post are not "write less, do more", they are "write less, do
> half the work".
>
> But well, what do I care? I never use them anyway ;)
>
> 2009/11/9 John Resig <jere...@...>
>
> > Ok, so I go back to my original statement: "Really the get and post
> > methods are meant to be simple cases, everything else should be
> > tackled with the ajax method."
>
> > --John
>
> > On Mon, Nov 9, 2009 at 4:48 PM, Julian Aubourg <aubourg.jul...@...>
> > wrote:
> > > Well, to be honest, I never ever use $.get or $.put (or $.getJSON). The
> > main
> > > reason is that there is no error callback which, in my opinion, makes
> > them
> > > completely useless in any production environment.
>
> > > Now I understand the convention being broken argument, but the two
> > callback
> > > solution:
> > > - does not break current code, ever,
> > > - does not necessitate jQuery to create a special error callback that
> > will
> > > redirect to the dual callback function,
> > > - does not necessitate branching in user code.
>
> > > I dunno, but for helper functions, I'd be willing to sacrifice some api
> > > purity and have them really useful yet backward compatible. But, then
> > again,
> > > I never had the responsibility of anything that's became as huge as
> > jQuery,
> > > so...
>
> > > 2009/11/9 John Resig <jere...@...>
>
> > >> > Wouldn't it still break some scripts that actually expect the data
> > never
> > >> > to
> > >> > be undefined?
>
> > >> As I mentioned before - the application would just break in a
> > >> different way. Normally it would break in that the result would never
> > >> come in - now it would throw an exception (again, that's assuming that
> > >> if they're trying to do something directly with the object - a more
> > >> likely result is seeing "null" outputted somewhere).
>
> > >> > Why not the following:
>
> > >> > $.get("someurl", function(data) {
> > >> >    // got results
> > >> >  }, function(errorMessage) {
> > >> >    // got error
> > >> >  });
>
> > >> > That way, actual scripts behave as usual and new ones can provide an
> > >> > error
> > >> > callback.
>
> > >> > Thoughts?
>
> > >> I'm not a huge fan of this - having dual functions being passed in as
> > >> arguments is messy and against the current jQuery conventions. I feel
> > >> like if you're passing in so many functions why not just use $.ajax
> > >> and be done with it? Especially since $.ajax is so much more explicit
> > >> any way.
>
> > >> Either we should find a simple solution (like what I proposed) or do
> > >> no change at all.
>
> > >> --John
>
> > >> --
>
> > >> 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@....
> > >> To unsubscribe from this group, send email to
> > >> jquery-dev+unsubscribe@...<jquery-dev%2Bunsubscribe@...>
> > .
> > >> For more options, visit this group at
> > >>http://groups.google.com/group/jquery-dev?hl=en.
>
> > > --
>
> > > 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@....
> > > To unsubscribe from this group, send email to
> > > jquery-dev+unsubscribe@...<jquery-dev%2Bunsubscribe@...>
> > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/jquery-dev?hl=en.
>
> > --
>
> > 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@....
> > To unsubscribe from this group, send email to
> > jquery-dev+unsubscribe@...<jquery-dev%2Bunsubscribe@...>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/jquery-dev?hl=en.

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[jaubourg]

Jason, I like what you're getting at.. a lot.

2009/11/9 Jason Persampieri <pappy74@...>

I agree with pretty much everything Julian said.  And while I don't
have a problem with $.get(url, onSuccess, onError), I can see how this
isn't "jQuery-like".

Right now, $.get returns an XmlHttpRequest object.  What if that
object were extended a bit?

$.get(url, callback).error( onError )

Or, heck, go even crazier.... all $.ajax calls return a jQueryAjax
Object (that responds to everything XmlHttpRequest objects do... for
backwards compatibility)... that could lead to

$.get(url).success( callback ).error( callback ).

Interestingly, this would lead to the ability to cleanly request a
resource, then define how you want to handle it later on, even after
it's already come back.

That's at least a *little* more jQuery-like :)

_jason

On Nov 9, 9:49 am, Julian Aubourg <aubourg.jul...@...> wrote:
> OK and well I guess, but I'll go back to my original statement too then:
> "simple cases don't protect from temporary connection and/or server
> shutdowns, do they?". Like I said, I will use $.ajax anyway, but let me
> re-iterate that simple in design (rather in signature here) does not mean
> suitable for simple cases. The OP problem is quite clear: for "serious work"
> (ie: in real world production), error handling is mandatory because no
> matter how simple the ajax call, error can (and will) occur. I'm afraid the
> simple cases you're refering to are nothing more than proof of concepts and
> I personally don't use jQuery to do prototypes but real world web sites.
>
> That being said, the current status of $.get and $.post also pushes
> developers into ignoring errors altogether which makes for plugins you have
> to modify (or just plain rewrite) for production use (sadly talking from
> experience here).
>
> Finally, handling error cases with $.ajaxError in that case is like crushing
> an egg with a grand piano.
>
> And before anybody jumps at my throat, let me say again that I mean no
> disrespect: I admire the work you guys put into jQuery and I shudder to
> imagine how I would develop without this fantastic toolbox but, as of today,
> $.get and $.post are not "write less, do more", they are "write less, do
> half the work".
>
> But well, what do I care? I never use them anyway ;)
>

> 2009/11/9 John Resig <jere...@...>

>
> > Ok, so I go back to my original statement: "Really the get and post
> > methods are meant to be simple cases, everything else should be
> > tackled with the ajax method."
>
> > --John
>

> > On Mon, Nov 9, 2009 at 4:48 PM, Julian Aubourg <aubourg.jul...@...>

> > wrote:
> > > Well, to be honest, I never ever use $.get or $.put (or $.getJSON). The
> > main
> > > reason is that there is no error callback which, in my opinion, makes
> > them
> > > completely useless in any production environment.
>
> > > Now I understand the convention being broken argument, but the two
> > callback
> > > solution:
> > > - does not break current code, ever,
> > > - does not necessitate jQuery to create a special error callback that
> > will
> > > redirect to the dual callback function,
> > > - does not necessitate branching in user code.
>
> > > I dunno, but for helper functions, I'd be willing to sacrifice some api
> > > purity and have them really useful yet backward compatible. But, then
> > again,
> > > I never had the responsibility of anything that's became as huge as
> > jQuery,
> > > so...
>

> > > 2009/11/9 John Resig <jere...@...>

>
> > >> > Wouldn't it still break some scripts that actually expect the data
> > never
> > >> > to
> > >> > be undefined?
>
> > >> As I mentioned before - the application would just break in a
> > >> different way. Normally it would break in that the result would never
> > >> come in - now it would throw an exception (again, that's assuming that
> > >> if they're trying to do something directly with the object - a more
> > >> likely result is seeing "null" outputted somewhere).
>
> > >> > Why not the following:
>
> > >> > $.get("someurl", function(data) {
> > >> >    // got results
> > >> >  }, function(errorMessage) {
> > >> >    // got error
> > >> >  });
>
> > >> > That way, actual scripts behave as usual and new ones can provide an
> > >> > error
> > >> > callback.
>
> > >> > Thoughts?
>
> > >> I'm not a huge fan of this - having dual functions being passed in as
> > >> arguments is messy and against the current jQuery conventions. I feel
> > >> like if you're passing in so many functions why not just use $.ajax
> > >> and be done with it? Especially since $.ajax is so much more explicit
> > >> any way.
>
> > >> Either we should find a simple solution (like what I proposed) or do
> > >> no change at all.
>
> > >> --John
>
> > >> --
>
> > >> 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@....
> > >> To unsubscribe from this group, send email to

> > >> jquery-dev%2Bunsubscribe@...<jquery-dev%252Bunsubscribe@...>

> > .
> > >> For more options, visit this group at
> > >>http://groups.google.com/group/jquery-dev?hl=en.
>
> > > --
>
> > > 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@....
> > > To unsubscribe from this group, send email to

> > > jquery-dev%2Bunsubscribe@...<jquery-dev%252Bunsubscribe@...>

> > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/jquery-dev?hl=en.
>
> > --
>
> > 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@....
> > To unsubscribe from this group, send email to

> > jquery-dev%2Bunsubscribe@...<jquery-dev%252Bunsubscribe@...>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/jquery-dev?hl=en.

--

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@....
To unsubscribe from this group, send email to jquery-dev%2Bunsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[John Resig]

> Jason, I like what you're getting at.. a lot.

I agree, I like it as well.

A completely different technique:

jQuery(jQuery.get("url")).bind("success", fn);

Then the jQuery.ajax method could call jQuery(xhr).trigger("success");

Hmm. It'd be neat if we could somehow return just jQuery(xhr) but
that's not really possible, not without breaking code, at least.

--John

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[jaubourg]

Yeah, $.ajax already returning jQuery(xhr) would be awesome, but talk about backward compatibility breakage... the real question being: how many actually do use the xhr as a returned value (as opposed to beforeSend for instance).

I have a question though... would jQuery(jQuery.get("url")).bind("success", fn); work if the request succeeds before the binding?

2009/11/9 John Resig <jeresig@...>

> Jason, I like what you're getting at.. a lot.

I agree, I like it as well.

A completely different technique:

jQuery(jQuery.get("url")).bind("success", fn);

Then the jQuery.ajax method could call jQuery(xhr).trigger("success");

Hmm. It'd be neat if we could somehow return just jQuery(xhr) but
that's not really possible, not without breaking code, at least.

--John

--

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@....

To unsubscribe from this group, send email to jquery-dev%2Bunsubscribe@....

For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[pete higgins]

This sounds a lot like Deferred/Promise APIs. +1

Julian Aubourg wrote:

> Yeah, $.ajax already returning jQuery(xhr) would be awesome, but talk
> about backward compatibility breakage... the real question being: how
> many actually do use the xhr as a returned value (as opposed to
> beforeSend for instance).
>
> I have a question though... would
> jQuery(jQuery.get("url")).bind("success", fn); work if the request
> succeeds before the binding?
>
> 2009/11/9 John Resig <jeresig@... <mailto:jeresig@...>>
>
>     > Jason, I like what you're getting at.. a lot.
>
>     I agree, I like it as well.
>
>     A completely different technique:
>
>     jQuery(jQuery.get("url")).bind("success", fn);
>
>     Then the jQuery.ajax method could call jQuery(xhr).trigger("success");
>
>     Hmm. It'd be neat if we could somehow return just jQuery(xhr) but
>     that's not really possible, not without breaking code, at least.
>
>     --John
>
>     --
>
>     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@...
>     <mailto:jquery-dev@...>.
>     To unsubscribe from this group, send email to
>     jquery-dev+unsubscribe@...
>     <mailto:jquery-dev%2Bunsubscribe@...>.
>     For more options, visit this group at
>     http://groups.google.com/group/jquery-dev?hl=en.
>
>
>
> --
>
> 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@....
> To unsubscribe from this group, send email to
> jquery-dev+unsubscribe@....
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[Scott Sauyet-2]

+1

> Hmm. It'd be neat if we could somehow return just jQuery(xhr) but
> that's not really possible, not without breaking code, at least.

It might just be possible, if jQuery(xhr) was then extended with the
xhr API.  I don't know if there is some overlap that would make this
impossible, and I'm really not sure it would be a good idea even if it
were possible.  I'm thinking of something like:

    return jQuery.extend(jQuery(xhr), {
        getResponseHeader: function() {return xhr.getResponseHeader();},
        statusText : // some initial value that's updated as the
underlying xhr object is changed
        // ...
    });

This is pretty ugly, as it's essentially writing our own XHR
implementation on top of the one in the browser, but it it were
workable, it would be both powerful and backward-compatible.

Probably I'm just smoking something, though...

  -- Scott

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.

[dave.methvin]

> Couldn't you just use the .ajaxError() method in conjunction with  
> $.get or $.post? That seems to work for me.

I use that technique as well, and it's nice because it gets the error
checking out of the way of the main code. I also have used a wrapper
plugin around $.ajax in some cases. Neither is burdensome.

$.ajax is already one of the most complex and least consistent methods
in jQuery, so if anything I'd like to see it get simpler. For example,
the method now handles jsonp requests (based on either dataType or the
domain in the url) but many of the completion methods expect a xhr
object which jsonp requests don't have.

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.

[dave.methvin]

> $.get(url, callback).error( onError )

That creates a potential race condition, since the async request is
made and may complete before the onError handler is attached.

--

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@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.