> Regarding the abort possibility for jsonp (#5500 => #3442), this brings us > back to the idea of returning an abstraction on top of the actual xhr/script > hack/whatever. > > I was curious as to why the whole ajax typology wasn't implemented with a > factory pattern: you would call something like XHRFactory.get(options) which > would return an abstraction with the same interface as an xhr. This would > hide routing into the factory code and all the hacks into the different > abstractions (including handling the replacement of ? with the callback > name, creating a script tag -- or an iframe in my own implementation of > jsonp--, etc, etc) and keep the ajax function clean (calling everything as > if it were pure xhr no matter the situation). Each implementation that do > not implement some features (like header manipulation for script hacks) > would simply do nothing when those methods are called. Plus, the interface > could be enhanced to handle the .bind(type,func) we talked about in the > other thread (and deferred error/success/etc callback bindings). > Furthermore, each implementation would be replaceable by user code (we could > keep the xhr setting active, it would only act on pure xhr calls). > > I'd be willing to give it a try (knowing you would more than surely have to > clean it up to jQuery's standards after), just let me know if I'm crazy or > something.
That's an interesting proposition - I'd be interested in seeing where you go with that. 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. --John -- 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=.
