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?
>
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
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 mostl
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
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
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 rec
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
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
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 creat
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 slo
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'
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
@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
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/jq
> 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 differe
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
"
16 matches
Mail list logo
