Last modified: 2012-06-23 14:03:55 UTC
mw.api.prototype.ajax and mw.api.prototype.post in JavaScript are offering 'err' and 'ok' in the ajaxOptions parameter to specify callbacks for error and success. It might be worth replacing this with the use of jQuery.Deferred, so instead of returning the jqXHR objectd they could return a new Deferred object so one can assign several callbacks to them. The jqXHR object shouldn't be of interest much I assume since it only tells about the ajax requests state and whether it failed, not about the api calls success. So the ajax can succeed but the api request could still have failed, this is not apparent when using the jqXHR object. If people use the jqXHR for some reason code could break if we would change the return values. Right now the 'ok' option is obligatory, we could change that so it isn't anymore and if it isn't provided, we would just return a custom deferred object.
I'm not sure what you are asking here. The only mention of jqXHR is in the comments of mw.Api. The method itself is a passthru from jQuery.ajax (the last line in both of the implementations is "return $.ajax( opt );" As of jQuery 1.5 jqXHR extends jQuery.Deferred() so it implements the promise interface etc. The following should work fine: <code> function myApiStuff() { var api = new mw.Api(); return api.get( {}, ... ); } var apiStuff = myApiStuff(); apiStuff.always( fn ); apiStuff.done( fn ); // etc. </code> See also http://api.jquery.com/jQuery.ajax/ A few things we could do in addition to that: * Make the "ok" argument to mw.Api..get optional, so that one can use the deferred methods without having to pass a bogus function as well.
Ah, I get what you mean now. Those methods tie into the ajax response directly, whereas the ok/err callbacks from mw.Api do some Api specific post-processing first. So yeah, we should indeed create our own Deferred object that waits for jqXHR's promise first.
Working on it.
Change-Id: I2986eec3c8827dcca34a17faf7ebeb80fd770b08
https://gerrit.wikimedia.org/r/10662
