Great thread, well done guys. I've been following this with interest
and wondered...
As part of the re-write, please could we improve the continuity of the
callback arguments?
It can be hard to remember what each callback receives.
At the moment they are:
success : function (data, textStatus)
error : function (XMLHttpRequest, textStatus, errorThrown)
complete : function (XMLHttpRequest, textStatus)
beforeSend : function (XMLHttpRequest)
ajaxStart : function ()
ajaxStop : function ()
ajaxSend : function (event, XMLHttpRequest, ajaxOptions)
ajaxSuccess : function (event, XMLHttpRequest, ajaxOptions)
ajaxComplete : function (event, XMLHttpRequest, ajaxOptions)
ajaxError : function (event, XMLHttpRequest, ajaxOptions,
thrownError)
Perhaps they could all receive something like:
function (data or event, XMLHttpRequest, textStatus, ajaxOptions,
thrownError)
Ok, that's a lot of arguments. Perhaps that needs more thought ;o)
I realise there are good reasons why they receive difference arguments
but continuity would be helpful even if one or two arguments are null
because they're not needed or not relevant in some callbacks.
Unfortunately this type of change will break plugins such as
jquery.ui.tabs but judging by other changes you've been discussing, it
seems that there will be many breaking changes.
Other wish list ideas are:
- Allow beforeSuccess and beforeComplete callbacks to be set up in
ajaxSetup (returning false from these would cancel success etc)
- Provide an event object in every callback.
- Provide some clue about the target element in all callbacks after $
(xyz).load() responds. Perhaps via the event.target attribute.
- Call ajax success and complete as part of a .load(). Currently the
load method overrides the complete callback.
Cheers,
George
On Nov 19, 4:32 am, Julian Aubourg <aubourg.jul...@gmail.com> wrote:
> Well, I was thinking about separating things into different files
> (ajax-something.js -- "main", "transport", etc) but I haven't looked into
> jQuery's building process and I'm *that* bad with anything that needs
> configuration, I'll will definitely need a hand on this.
>
> I'm all for post 1.4 actually. I think it would be wrong to push this change
> too early especially given 1.4 release is getting damn close and the changes
> we're talking about will require extensive regression testing. It can always
> be introduced in a 1.4.x release as soon as backward compatibility is
> ensured.
>
> Also, I admit I don't have as much time as I'd like to work on it right now
> and I'm pretty sure I'll also have to rework things before it's good for
> production.
>
> 2009/11/19 John Resig <jere...@gmail.com>
>
> > Github works for me - and editing ajax.js (and test/unit/ajax.js) would be
> > ideal - that way we could just merge it directly in.
>
> > If there's any way to make your changes piece-by-piece that'd be excellent
> > as it would make the full scope of the changes easier to understand.
>
> > Also, don't feel entirely bad if this gets bumped until after 1.4 - it
> > sounds like a lot of code might be changing and I'd rather do it right,
> > once, then badly twice.
>
> > --John
>
> > On Wed, Nov 18, 2009 at 10:52 PM, Julian Aubourg <aubourg.jul...@gmail.com
> > > wrote:
>
> >> Not yet, I'll wait to have at least one transport made (I'm working on the
> >> xhr one atm) and all the layers tested... wouldn't like to put some code
> >> with obvious mistakes that some rough testing will get rid of. I thought
> >> about unit testing early, but truth is the amount of refactoring at each
> >> iteration makes it impossible to cope with. Once I have something stable
> >> codewise and roughly tested, I'll put it on github. OK with you?
>
> >> btw, do you prefer I edit ajax.js or that I upload a plugin (which is the
> >> format I'm using right now)?
>
> >> 2009/11/19 John Resig <jere...@gmail.com>
>
> >> All of this sounds pretty good - do you have a link to the code?
> >>> (Preferably in a fork up on Github - makes it easy to do a code review.)
>
> >>> --John
>
> >>> On Wed, Nov 18, 2009 at 10:10 PM, Julian Aubourg <
> >>> aubourg.jul...@gmail.com> wrote:
>
> >>>> OK, just a post to keep you all updated since I didn't get as much time
> >>>> as I expected though I have progress, mind you.
>
> >>>> Also, I recommend a good understanding of the internals of $.ajax to
> >>>> follow everything.
>
> >>>> First, let me start with some design decisions I came up with:
>
> >>>> 1) the fake XHR returned by $.ajax only emulates header related methods
> >>>> & abort
>
> >>>> The rational behind the decision is as follows:
> >>>> - the onreadystatechange callback was already used by jQuery internally
> >>>> on the old implementation, meaning that using it was pointless if not
> >>>> plain
> >>>> wrong.
> >>>> - same goes for open & send, it doesn't make sense for external code to
> >>>> use them
>
> >>>> On a sidenote, readyState could be emulated but I fail to see the point.
> >>>> I *could* emulate onreadystatechange but is there really a use case for
> >>>> this?
>
> >>>> Of course, the complete(), success() & error() methods are implemented.
> >>>> If you do something like
> >>>> jQuery.ajax(options).complete(completeCallback); in
> >>>> async=false mode, the completeCallback method WILL be called with correct
> >>>> arguments even though the request already completed.
>
> >>>> Each callback family handled "return false;" in callbacks, meaning no
> >>>> further callbacks of that family will be called later on.
>
> >>>> For backward compatibility, the complete, success & error callbacks
> >>>> provided in the options object are also called (they are actually added
> >>>> to
> >>>> the list of callbacks before issuing the request).
>
> >>>> 2) I added the notion of "transport" which is the actual implementation
> >>>> that will send the request
>
> >>>> ajaxSettings has two new properties:
> >>>> - transportSelector, a function that will take an options object and
> >>>> determine what transport type is more suited for the request,
> >>>> - transportDefinitions which is a hashmap of transport definitions
> >>>> (obviously).
>
> >>>> Transport definitions contains two functions:
> >>>> - filter which takes the options object & returns a new transport type
> >>>> if it deems it more suited than itself
> >>>> - factory which takes no argument & returns a new transport of the
> >>>> desired type
>
> >>>> The idea in having the filter function is:
> >>>> - to set s.global as false if the transport cannot ensure completion
> >>>> (cross-domain script / jsonp),
> >>>> - to keep differentiating code as close to the implementation as
> >>>> possible. A good example are scripts which wont be handled the same if
> >>>> they
> >>>> are cross domain or not (first will use xhr, second will use a script
> >>>> tag).
> >>>> If s.transportDefinitions[transportType] is not an object but a
> >>>> function, it
> >>>> is considered a filter. Following previous example, transportSelector
> >>>> would
> >>>> just return "script" no matter what, and the script transport definition
> >>>> would look like this:
> >>>> s.transportDefinitions["script"] = function (s) { return
> >>>> isCrossDomain(s) ? "script-tag" : "xhr" }
>
> >>>> Filters get called until a final transportType is found, then the
> >>>> corresponding transport factory gets called.
>
> >>>> By changing transportSelector & transportDefinitions, a user can
> >>>> completely
>
> >>>> I also added some options into the ajax options object beside
> >>>> transportSelector & transportDefinition:
> >>>> - transport: which can be used to bypass transportSelector (filters
> >>>> called until final type is found are not bypassed)
> >>>> - transportDataType: it's the data type used to determine which
> >>>> transport to use (in transportSelector), if not provided it's equivalent
> >>>> to
> >>>> dataType. The idea came when I was refactoring and realized that it was
> >>>> no
> >>>> reason why you couldn't ask for xml through jsonp. So you would have
> >>>> something like $.ajax({ dataType: "xml", transportDataType: "jsonp",
> >>>> ...})
> >>>> and the request will be made through jsonp and the resulting json object
> >>>> will be parsed as xml (I already implemented the logic). As a consequence
> >>>> dataFilter gets 3 arguments:
> >>>> - the data,
> >>>> - s.dataType,
> >>>> - a function that permits to get/set the transportDataType (so that you
> >>>> can make "casts" in your dataFilter).
> >>>> - crossDomain: a boolean computed into the main $.ajax method to make
> >>>> life of filters easier.
>
> >>>> So far, I have:
> >>>> - the logic in $.ajax (with xhr emulation & callbacks system),
> >>>> - the factory system,
> >>>> - a helper function to help create transports (in the end only 3
> >>>> functions + the filter will have to be provided to create a new
> >>>> transport),
> >>>> - the interface for a transport (which is much easier to deal with than
> >>>> an xhr).
>
> >>>> I have yet to implement actual transports and start testing.
>
> >>>> Also, generalizing the implementaton, global events, timeout,
> >>>> ifModified, etc, are handled for all transports (now, given lack of
> >>>> headers,
> >>>> ifModified may not have an effect with most transports but still).
>
> >>>> The code hasn't exploded in size but I cannot estimate yet how bigger it
> >>>> will get.
>
> >>>> Now onto stuff I'd like to see in jQuery and am very tempted to add in
> >>>> the process is ful-fledged support for CORS with the definition of
> >>>> jQuery.support.crossDomainRequest (values false, "standard" or
> >>>> "XDomainRequest" -- detection code can be found here:
> >>>>http://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors/--).
> >>>>Using filters and the new s.crossDomain computed option, it should be
> >>>> very easy to handle all situations (by throwing an exception or whatnot
> >>>> so
> >>>> that client code could fallback on a proxy or something).
>
> >>>> Feedbacks welcome is you see anything gross in there.
>
> >>>> -- Julian
>
> >>>> 2009/11/15 Julian Aubourg <aubourg.jul...@gmail.com>
>
> >>>> I looked into your code and we basically have the same approach. I'll
> >>>>> try & get the refactoring done by the middle of next week (like I said,
> >>>>> I
> >>>>> have social life getting in the way right now ;) ).
>
> >>>>> 2009/11/15 Shade <get...@gmail.com>
>
> >>>>> I've built two different JavaScript projects which implement a nearly
> >>>>>> identical interface to the native XHR object, including updating
> >>>>>> properties, etc, while hiding under the covers how the actual XHR
> >>>>>> happens. One is flXHR (http://flxhr.flensed.com) which actually has a
> >>>>>> jQuery plugin that adapts flXHR to be automatically selected and used
> >>>>>> by jQuery when making $.ajax calls. It relies on the XHR registry
> >>>>>> plugin of jQuery. Because flXHR exposes the identical interface to
> >>>>>> native XHR, this makes it able to be used throughout $.ajax without
> >>>>>> any changes to jquery itself.
>
> >>>>>> The other project isn't specifically jQuery related, but it's called
> >>>>>> jXHR (http://mulletxhr.com).
>
> >>>>>> The reason I mention these two projects is that they seem to be doing
> >>>>>> exactly what is being suggested with this mockXHR object. I use a
> >>>>>> couple of tricks to make that happen, including emulating updating
> >>>>>> properties. I'd be willing to collaborate on this solution and share
> >>>>>> the tricks I used in my two projects.
>
> >>>>>> Let me know if this would of assistance. I definitely support trying
> >>>>>> to revamp the way the $.ajax system works to give it more
> >>>>>> extensibility.
>
> >>>>>> --Kyle
>
> >>>>>> On Nov 13, 4:38 pm, Jason Persampieri <papp...@gmail.com> wrote:
> >>>>>> > On Nov 13, 6:39 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
>
> >>>>>> > > On
>
> ...
>
> read more »
--
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-...@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.
