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 Thu, Nov 12, 2009 at 1:15 PM, John Resig <jere...@gmail.com>
>>>> wrote:
>>>> > > >> I think the one area that would be troublesome is in the
>>>> properties
>>>> > > >> that xhr provides (like readyState, responseXML, etc.). I'm not
>>>> sure
>>>> > > >> how you'd build this mock XHR and keep those properties up to
>>>> date.
>>>> >
>>>> > > On Thu, Nov 12, 2009 at 10:14 PM, Julian Aubourg
>>>> >
>>>> > > <aubourg.jul...@gmail.com> wrote:
>>>> > > > As an example of what I'm talking about with an real xhr as a
>>>> base:
>>>> > > > - layer 0 is window.ActiveXObject ? new
>>>> ActiveXObject("Microsoft.XMLHTTP") :
>>>> > > > new XMLHttpRequest()
>>>> > > > - layer 1 is a standard compliant xhr implementation that
>>>> delegates to layer
>>>> > > > 0 while hiding browser incompatibilities. It listens to layer 0
>>>> through its
>>>> > > > onreadystatechange event handler and propagates the event by
>>>> calling its own
>>>> > > > onreadystatechange if available
>>>> >
>>>> > > I had briefly mentioned a similar idea in the other thread [1], but
>>>> > > was rather scared of the actual implementation. I guess the
>>>> question
>>>> > > is whether there are possible state changes to the underlying XHR
>>>> > > object that might affect the properties but that are not exposed
>>>> > > through the onreadystatechange handler. I don't have nearly the
>>>> > > knowledge of XHR to answer this. If there aren't any, I think this
>>>> is
>>>> > > quite a good idea.
>>>> >
>>>> > > -- Scott
>>>> >
>>>> > > [1]http://tinyurl.com/yl2lqjz#msg_1fa4cac00dbcedcf
>>>> >
>>>> > Well, then. I had started working on something similar, but much
>>>> > simpler. I had planned to intercept the return value of $.ajax and
>>>> > extend it with 'success' and 'error' functions. Of course, I hadn't
>>>> > gotten to the point of actually testing this, so who knows if it would
>>>> > have worked. Your solution sounds much more robust and forward
>>>> > thinking. Very nice.
>>>> >
>>>> > _jason- Hide quoted text -
>>>> >
>>>> > - Show quoted text -
>>>>
>>>> --
>>>>
>>>> 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<jquery-dev%2bunsubscr...@googlegroups.com>
>>>> .
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/jquery-dev?hl=.
>>>>
>>>>
>>>>
>>>
>> --
>> 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<jquery-dev%2bunsubscr...@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/jquery-dev?hl=.
>>
>
> --
> 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<jquery-dev%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=.
>
--
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=.
