Rolling Your Own AJAX (Part 3)

I'm looking through the Ajax library source code and noticed something that made me laugh. Three of the five objects were written using JSON and the others were constructed the more traditional way (creating functions to represent the object and defining members using the "this" keyword). Normally, I'm not this inconsistant but hadn't used JSON before and wanted to develop some proficiency. The reason being that deserializing JSON into a native JavaScript object is considerably faster than creating and working with an XML document (although there are security implications). That said, I think any reusable framework needs to support should probably support both, as well as simple string responses.

One of the challenges I ran into when coding this model was getting the message data to be accessible to the context object. The problem was this--the message contains a pointer to a callback function along with a reference to the request object. What I wanted to do was pass the entire parent message object to the callback. This would allow all of the request and response details, along with the properties of the message to be available when synchronized back to the main execution thread. But there's a problem.

The issue came with the "this" keyword. The AjaxMessage object contains a method called "process" which obtains a reference to a request object. This is temporarily stored in a property and the message object calls the "send" method of the request. When the onreadystatechange fires, the context becomes the request object; the reference to the parent message object is lost.

This was actually a simple fix for Firefox. The open-endedness of JavaScript objects would allow a property to be added to the request object with a reference back to the parent AjaxMessage. IE however is a different animal. The HTTPRequest is not exposed as a native JS object, but rather as an ActiveX control which plays by its own rules. This is actually related to the inability to cover a select box with a div object without the use of programming trickery (I prefer the iFrame shim myself). This problem gave me fits for over a week. So what was the solution?

It actually turned out to be pretty simple and logical. I was able to create a local variable that contained a reference to the AjaxMessage within said message.
When the "this" keyword picked up the HTTPRequest reference, I was able to get back to the message by passing the local reference as an arguement to the callback. At this point you may be thinking the same thing I was...with all this circular referencing going on, have we created a memory leak? The short answer is not that I've seen yet, but I'll go into further detail in a future blog.

Anyway, I've been using the Ajax library for a while now and have had great results. It's small (about 400 lines of code), reliable, handles a variety of page types and load, and very easy to plug in and use. If anybody is interested, you can download it here and use it at will. I'd love to hear about any bugs, feature requests, or general feedback.