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. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
