Well, here is how this mini-project evolved so that you can get an idea how it became what it is.
- At first I thought about a kinda enhanced $.ajaxSettings.xhr() with a simple factory and that's it. - Then I realized this would have meant a lot of code to provide by "transport" developpers, mainly the emulation of readyState & onreadystatechange which, in turn, meant cumbersome code to handle the silliest callback system I ever came by in the main function. Also, I saw that I had to provide a wrapper anyway, in order to implement late complete, success & error binding. - So the idea went like this: + make as much as possible with the wrapper + make transport implementation as simple as possible (a filter, 2 to 3 methods and that's it -- have a look in src/transports, you'll see how simple it is to implement one : that is MUCH simpler than implementing a complete xhr emulation) - I also took the liberty to rework the data checks & transformations which were hardcoded and took the opportunity to allow some nice features like xml over jsonp and such. As of today, you can add an entirely new type format along with custom transports (let's say "dom" as a weak example so that request directely serve dom trees). Anyway, as the code is now, you'll get timeout, callbacks, config pre-treatments (cache for instance) and all that out of the way. You can concentrate on what a transport is supposed to do : transport. Beside, from an architecture point of view, everything is bordered now, for instance all the hacks around browser vendors xhr implementations are in transports/xhr.js (with the exception of the xhr construction which stays in ajaxSettings for historical reasons). I invite you to browse the current implementation of ajax and make sense of those hacks in it -- they are, basically, everywhere -- or, even better, of the script tag hacks in there and the actual workflow of a jsonp request over xhr (nearly caused me nightmares ;)). It's still a work in progress and I feel like I can simplify a lot of things (especially the extra layer to handle callbacks). I'm also not that sure about the way transport selection is made (dataTypes do not strike me as the best way to do so but I went that way to comply with current implementation). Talking about current implementation, there is quite a lot of workarounds in my patch that have been added for compatibility reasons. Last, but not least, I'm still wondering if a full readyState and onreadystatechange emulation on the jQueryXHR wrapper would be interesting (I saw a message on the mailing list regarding re-using the xhr returned by $.ajax() for later requests which I find is a bad idea given how the xhr is handled internally but I still wonder if it's current practice -- as of now, transports are one time only beasts). Anyway, if you already have a complete xhr implementation, simply replace ajaxSettings.xhr() and you're done, it'll work as expected. You can also still use the plugin you already use : it'll work. Thing is, with the new architecture, you can force your implementation to be used for all situations (including those when current implementation would use a script tag hack for instance) by redefining transport factories. Of course, I still have to work on the options filtering thingy to make it less of a spaghetti labyrinth -- and any suggestion is welcome. Hope I made my choices a little clearer. 2009/12/2 Shade <get...@gmail.com> > I'm still a little confused as to why the XHR (with "transport") > plugin doesn't give us what we need in terms of being able to provide > an alternate XHR-like transport that $.ajax will use? > > I found it to be quite graceful and succinct for what I was doing with > flXHR and the jQuery.flXHR plugin. > > This is the official "XHR Registry" plugin for jquery that I use to > select the transport as flXHR: > > http://plugins.jquery.com/project/XHR > > > And inside my plugin, all I do to use that XHR registry is this: > > $.xhr.register('flXHRproxy',function(as) { > // "as" is the options object passed to any of the ajax calls > // this function simply needs to decide which "XHR" object to > instantiate and return. It can either return the native one > // like this: $.xhr.registry['xhr'](as); > // or it can substitute in another one and return that > }); > > > My point is, instead of really re-wiring all the internals of $.ajax, > couldn't we just use this plugin to substitute in a "smarter" XHR > object that all the different features we want? > > --Kyle > > > > > On Dec 2, 10:03 am, Julian Aubourg <aubourg.jul...@gmail.com> wrote: > > I started cleaning the code and I think it's already in a good enough > shape > > now for some code reviews/remarks/ideas, etc. > > All tests pass under webkit browsers, Opera & Firefox (only latest > versions > > tested). IE8 has two failing tests (3 but the third doesn't fail if the 2 > > previous ones aren't ran) I haven't tested in previous versions. > > > > This bug is quite fun in fact. It seems there is a problem in the deep > copy > > algorithm when there is an object of type "DispHTMLDocument" (according > to > > IE's debugger) when trying to access its "fileCreatedDate" field (line > 268 > > of core.js) : we get a marvellous "unspecified error". Anyway, it means > > putting a context option in the ajax option object makes it fail at the > very > > first line of $.ajax. Can anybody confirm it also happens on the master > > under IE8? At first I thought it was because of the new options I put in > > ajaxSettings but, unless there's some crazy side-effect involved here, > it's > > quite unlikely. > > > > I suppose this is related to the discussion regarding spotting real > object > > litterals to avoid this kind of mess. Strange thing is, only IE has a > > problem with it and I was wondering if there was a non-standard way to > spot > > built-in types to circumvent it? > > > > Anyway, I need to implement cross-domain tests (so that I can confirm the > > addition of XDomainRequest support). > > > > -- Julian > > > > 2009/12/2 John Resig <jere...@gmail.com> > > > > > > > > > Phew - this is a beast of a patch indeed! In general though I'm liking > > > the feel of the resulting code, a lot. This would be much more > > > extensible, which is quite nice. I say we try to pursue this post-1.4. > > > > > In the meantime you can start to apply some of the jQuery Core Style > > > Guidelines to your code to get it ready for inclusion: > > >http://docs.jquery.com/JQuery_Core_Style_Guidelines > > > > > Naturally, making sure that all the tests pass as well is a great way > > > to make sure that the code lands. > > > > > --John > > > > > On Tue, Dec 1, 2009 at 8:21 PM, Julian Aubourg < > aubourg.jul...@gmail.com> > > > wrote: > > > > Thanks Dave but I think I kinda figured it out! > > > > > > Anyway, the code has been comitted athttp:// > github.com/jaubourg/jquery > > > > > > I don't have time to write everything about it down right now but you > can > > > > all have a look at least. > > > > > > 2009/12/2 Dave Methvin <dave.meth...@gmail.com> > > > > > >> > OK, so I have implemented my solution: > > > > > >> > Anyway, for the time being, my branch is sitting on my harddrive. > Why? > > > >> > Well, > > > >> > I've been practicing source control for years now but I have to > admit > > > I > > > >> > never encountered something as cryptic and unfriendly as git. > > > > > >> > So, if anyone has clear step in order to commit with this zealot, > > > please > > > >> > do > > > >> > share before I commit suicide. I made a fork of jQuery on github > btw. > > > > > >> Julian, I'm still coming up to speed with Git on Windows myself, and > > > >> stuck at trying to push my changes back to my fork on Github. I'm > > > >> going to start a new thread here about it. > > > > > >> -- > > > > > >> 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> > <jquery-dev%2bunsubscr...@googlegroups.com> > > > . > > > >> For more options, visit this group at > > > >>http://groups.google.com/group/jquery-dev?hl=en. > > > > > > -- > > > > > > 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> > <jquery-dev%2bunsubscr...@googlegroups.com> > > > . > > > > For more options, visit this group at > > > >http://groups.google.com/group/jquery-dev?hl=en. > > > > > -- > > > > > 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> > <jquery-dev%2bunsubscr...@googlegroups.com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/jquery-dev?hl=en.- 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=en. > > > -- 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.
