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 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<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=.
