Well, the idea is to enable Jason Persampieri's idea of a chaining ajax
system (ie $.ajax(options).success(...).error(...) ) while not having race
conditions (so the bind method will be smarter than your usual one) and
while maintaining compatibility with xhr.

So basically, all ajax request systems & hacks (real ajax, jsonp, script,
etc) will be wrapped into an xhr-like object (that is an object you'll be
able to use as an xhr) plus jQuery-only methods (allowing deferred callback
binding and the use of several complete, error & success callbacks for the
same request).

I've just began working on the pure xhr wrapper and I can already see how
all the hacks to circumvent xhr incompatibilities between browsers have been
scattered all around $.ajax and its submethods. Using a wrapper, I can
already put them all in one place (ie: the xhr wrapper ensures a not
modified response always has 304 as a status, onreadystatechange will always
be called even in async mode on firefox 1.5, won't throw exceptions when
headers are not available, etc, etc, there are too many little glitches to
list here but you get the idea).

I'm moving code around as we speak and I've set it all up as a plugin
external to jQuery core for now to be safe. The idea is to keep the source
as close to the current one as possible to avoid silly regressions (you
know, when you see some code, tell yourself you can do better but fail to
realize there are bug fixes in there). As far as I can tell, it's already
quite promising from a maintenance point of view.

I think I'm gonna built the wrapping system in three layers (bottom to top):
- layer 0 is the implementation (xhr for ajax, script tag hack for script &
jsonp)
- layer 1 is a standard-compliant xhr wrapper
- layer 2 is an augmented xhr with callback handling

The difference between layer 2 & 1 makes for a better and more readable
separation of concern. So basically, you get the layer 1 wrapper from a
factory given the dataType then wrap it into the callback aware one.
Everything is classes (functions + prototype) and I'm making sure there are
as few dynamically created methods/functions as possible. Anyway, in the
end, you have *1* layer 2 class which can accept any of the layer 1 classes
(one layer 1 class per remote request system -- ajax, jsonp, etc...).

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
- layer 2 is a standard compliant xhr that listens to layer 1, provides
methods to bind & notify events and actually does notify events, of course.

Dunno if I make myself clear... but it's like 4 am passed in here ;)

Anyway, I just moved from Paris to Brussels (I had intermitent internet the
last few days) and I have guests this week-end (heh! social life!) so I'll
try to have something concrete to show for the middle of next week.

2009/11/13 Dave Methvin <dave.meth...@gmail.com>

> Julian, could you show a few sample usages of the new design you had
> in mind?
>
> --
>
> 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=.


Reply via email to