Commit
…ope to move them there some day. Fixes #7146.
- Loading branch information
There are no files selected for viewing
7 comments
on commit 6245ecb
There was a problem hiding this comment.
My only question is: why? Are some people toying with the active counter by hand?
There was a problem hiding this comment.
Apparently - yes. Also some plugins were overwriting $.ajax with another function - causing them to break (as they didn't have the necessary functions any more). We can try to push for this in jQuery 1.5 - and use the 1.4.3 release as an opportunity to warn people.
There was a problem hiding this comment.
Sign me on this. Maybe the bigger issue is to sensibilize jQuery devs about not shaking the internals of the lib every chance they get ;)
There was a problem hiding this comment.
i know malsup's Taconite plugin replaces jQuery.httpData. maybe that's why it stopped working when i tested 1.4.3pre a few months ago :\
There was a problem hiding this comment.
I'm all for this change, quick question though: for a plugin that is specifically designed to override $.ajax (eg. http://github.com/appendto/jquery-mockjax), would the better process be something like this?
var _oldAjax = $.ajax;
$.ajax = function () { ...do stuff... };
$.extend($.ajax, _oldAjax);
There was a problem hiding this comment.
@gilmoreorless: Yeah, that'd be a good start. Additionally it'd be good to not assume anything about the 'this' inside those methods (it seems like a few methods were doing this.triggerGlobal (a method not found on jQuery.ajax - but found on jQuery itself).
There was a problem hiding this comment.
I know I was really tempted to override $.ajax back when I first worked on jQuery-jsonp and that's what I did at first but I then decided to create a new method altogether. The rationale was as follows:
- replacing an existing method meant it would have been exposed to any change to the contract and internals throughout new jQuery releases,
- replacing
$.ajax with $ .jsonp in user code is quite a simple process as long as the method's contract is close to the original one as of current jQuery version.
Now, the downside is that your code doesn't get executed by the other ajax-related methods (get, post, etc). Yet, these other methods are just syntactic sugar after all and I think it's a small price to pay in order to avoid potential conflicts everytime something is moved inside non-documented portions of jQuery.
As for taconite, it's another matter entirely seeing as it's plugging itself into an architecture that is not meant to be pluggable (ie. overriding the undocumented httpData). jQuery-mockjax is yet another type of beast that is doomed to depend on changes in contract just like any other dev tool (like jQuery-lint http://james.padolsey.com/javascript/jquery-lint/ ).
My opinion is, while all those plugins are cool and I see no reason for their authors not to go with them, it could be a good idea to inform the jQuery team of any difficulty regarding implementing them "cleanly" so that changes can occur in the internals of the library to help plugin developers. Be it with a forum post or a pull request.
I'm personally very interested in such demands seeing as I'm currently working on a pluggable architecture for ajax but it is clear this goes beyond jQuery.ajax and concerns most of jQuery's methods.
Sorry for the wall of text ;)
Is it possible to create a reference from jQuery.ajax.handleSuccess to jQuery.handleSuccess? This way you could evangelize the use of the new method instead of the old in the documentation, preparing for future releases.