Rolling Your Own AJAX (Part 2)

I left off talking about some of the perceived UI benefits of using AJAX. What I'd like to cover now is how I modeled the AJAX client library for this project. I did some research into some of the existing solutions, and there is some good stuff out there. Dojo is a very robust client-side library that goes way beyond simple AJAX functionality, and there a couple of .Net frameworks available, too (Ajax.Net and Atlas come to mind...I'm sure there are many more). For the project at hand, I decided to construct a framework from scratch--a direction I almost always lean toward.

Here is the object model I came up with, and the general rolls each would play:

• AjaxMessage: This object encapsulates a single callback to the server, and contains the request details, response details, and handling details (a reference to the callback function). It also contains the actual HTTP request (which I will most likely decouple when I refactor this puppy).


• MessageBuffer: This object is essentially a traffic controller, and determines how messages will be handled in the context of the page. When going through possible AJAX use-cases, I felt like we needed a lot of control here. In the project at hand, the user had the ability to request information faster than it could be processed. The MessageBuffer object can be set up to send messages immediately or in batches, and can filter duplicate messages.


• MessageCache: This is a repository for "cachable" messages. If a message is deterministic (will return the same results with the same inputs), it can be cached and the return data accessed later without going back to the server. This object manages cache settings including capacity, threshold, and expiretype (messages can be set to expire after a given amount of time, or via a least-frequently-used algorithm.)


• CacheObject: This is simply an AjaxMessage object with cache meta-data.


• Request Pool: OK, this was something I coded before had fully researched it. The idea was to create a pool of HTTP Request objects when the AjaxFramework is initialized to avoid the overhead of object creation for each request. Great idea in theory, right? The problem is the HTTP 1.1 specification says that only two request objects can be open by a browser simultaneously. IE adhere to this by default (although it can be changed in the registry) while Firefox has a default of eight. Oh well, if this changes in a future release, I'll be ready ;)

Here's what the model looks like for you UML folks out there:



Next, I'll get into some of the implementation details and specific features of the framework.