[jquery-dev] Re: $.ajax's error callback: Confusion with status codes and dataType
On Mon, Sep 7, 2009 at 8:19 PM, John Snyders wrote: > > > On Sep 7, 6:24 pm, Nathan Bubna wrote: >> On Mon, Sep 7, 2009 at 12:08 PM, John Snyders 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
On Mon, Sep 7, 2009 at 5:35 PM, Daniel Friesen 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 wrote:
>
>>
>> On Mon, Sep 7, 2009 at 12:08 PM, John Snyders
>> 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 wrote: > On Mon, Sep 7, 2009 at 12:08 PM, John Snyders 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
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 wrote: > > On Mon, Sep 7, 2009 at 12:08 PM, John Snyders > 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 3:19 PM, John Snyders 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 Snyders 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
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 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 wrote:
>
> > 2009/7/23 John Resig :
>
> > > 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
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 wrote:
> 2009/7/23 John Resig :
>
> > 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: $('selector').live( function() { } )
I just wanted to clear up any potential confusion here. My plugin doesn't actually rely on DOM Mutation Events being supported by the browser, it merely emulates the actual Mutation Event fields. I see now that livequery fulfils a similar role - I wasn't actually aware of this at the time I created the plugin, thanks for heads up on this John. Someone else has also produced a similar plugin that can trigger events on any jQuery.fn.* call - I can't for the life of me remember who it was though, or find it! - Mark 2009/9/7 John Resig : > Just be aware the mutation events don't work in all browsers. If you want > similar functionality to what you proposed you can use the liveQuery plugin: > http://plugins.jquery.com/project/livequery/ > > We debated adding something like this to core, but the overhead ended up > being very high (every single element inserted into the page needs to be > scanned before insertion). > > --John > > > On Mon, Sep 7, 2009 at 8:25 AM, ludovic wrote: >> >> @Mark >> Thanks, >> I'll try your plugin >> Regards, >> Ludovic >> > > > > > --~--~-~--~~~---~--~~ 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: jQuery Dynamic Composition
All I'm saying is, what has been proposed is a rather mighty task -
and it's all because of one browser. It works in IE most of the time
at an apparent good speed, just as any other browser. The question I
put forth is, why do such big changes just for IE just for the few
times it does go more slowly? Why not just work on correcting those
few things!
However, that said if people want to do this then why not? After all,
a faster jQuery library can only be a good thing right? Ultimately
this type of optimisation could be the stepping stone for banishing
all speed issues permanently and would help to keep jQuery at the
forefront of javascript libraries.
I ran some more tests with jQuery:
1. To determine if conditionals to detect IE vs non-IE were slow - No
difference in jQuery to the tests in my last post, even when unrelated
code was much longer than the IE section. E.g.
if (jQuery.support.cssFloat) {
$("p").html($("p").html()); // Non - IE
$("p").html($("p").html());
$("p").html($("p").html());
$("p").html($("p").html());
$("p").html($("p").html());
$("p").html($("p").html());
$("p").html($("p").html());
$("p").html($("p").html());
$("p").html($("p").html());
} else {
$("p").html($("p").html()); // IE
}
It seems the amount of unrelated script is not a problem for IE.
2. To determine if retrieving information was as slow as setting it.
Yes, IE is 3 times slower in that area as well, with it taking about
15 ms to retrieve the html and firefox only 5 ms. Let's put this into
perspective:
'$("p").html($("p").html());':
This takes IE about 150 ms and firefox about 50 ms to execute 100
times. At what point do delays become macroscopic. At about 100 ms???
Also, sorry, I realise I talk as though I am a developer, but indeed,
I am not!
Best Regards,
Paul
--~--~-~--~~~---~--~~
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: $('selector').live( function() { } )
Thanks, It was always possible to insert it into the core without altering performances : you just have to scan only if there has been at least one event binding of this kind. Thus, there wouldn't affect performances for thoses who don't use this functionality, and for those who use it, it wouldn't be slower than using a plugin. Regards, Ludovic --~--~-~--~~~---~--~~ 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: $('selector').live( function() { } )
Just be aware the mutation events don't work in all browsers. If you want similar functionality to what you proposed you can use the liveQuery plugin: http://plugins.jquery.com/project/livequery/ We debated adding something like this to core, but the overhead ended up being very high (every single element inserted into the page needs to be scanned before insertion). --John On Mon, Sep 7, 2009 at 8:25 AM, ludovic wrote: > > @Mark > Thanks, > I'll try your plugin > Regards, > Ludovic > > > --~--~-~--~~~---~--~~ 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: $('selector').live( function() { } )
@Mark Thanks, I'll try your plugin Regards, Ludovic --~--~-~--~~~---~--~~ 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: $('selector').live( function() { } )
Hi Ludovic, I created a plugin that fires events based on the DOM Mutation Events specs. It hooks into various jQuery functions, html(), attr() etc, and fires an event when content is changed. Docs: http://www.adaptavist.com/display/free/jQuery+Mutation+Events Code: http://github.com/jollytoad/jquery.mutation-events - Mark. 2009/9/3 ludovic : > >> Check the documentation first. > I know the documentation :) and one doesn't answer to my need for two > reasons : > > - one doesn't make a live binding, so it works only on present nodes > and not futures > - one and live bind events, but I want to execute code when a new node > has been added and not after a click or anything else. > > My idea was to create a kind of cross-browser DOMElementAdded event, > and to add the live support for this event. > > Regards, > Ludovic > > > --~--~-~--~~~---~--~~ 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: jQuery Dynamic Composition
> 1. it is *not* just about the speed > If it would be then why using jQuery? For compatibility issues. Here is the situation : either we use low level functions which are faster, but we aren't sure it is compatible, or we use jquery which is slower. The benchmark of Moi Ce Soir shows the difference, but what we don't know is whether the slow code is made by one or two slow functions or if it is only due to the instructions number. Ludovic --~--~-~--~~~---~--~~ 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: jQuery Dynamic Composition
1. it is *not* just about the speed If it would be then why using jQuery? 2. IE we can not ignore If we could then why complicating jQuery with IE workarrounds? --DBJ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
