Introducing AJAX

A little over a year ago I described AJAX and the work I was starting to research into it. Back then I was calling it RPC (Remote Procedure Call), since I thought it made more sense than the term AJAX (Asynchronous Javascript and XML) as we techincally weren’t using XML.

Since then AJAX as a term has become pretty widespread and ubiquitous, as has its impact on the web. Now we can add the Walker to the large list of sites using this technology.

If you head over to our Art on Call website, you may notice a few changes to our stops list. Gone is the long list of stops, and in it’s place is a searchable, sortable, paginated view of our info. All of this happens dynamically without refreshing the page.

The way I went about writing this is a bit different from normal AJAX. With typical AJAX, you request XML data and load it into memory. Then you parse the the XML by various means, either using Javascript to pull data out of nodes, or an XSLT processor built into many modern browsers. The result of course is HTML, which you output to the page to update content when a user requests it.

There are two benefits to the normal approach. One is that it takes any translation processing off the server load and puts it onto the users machine, allowing the server to be more responsive. Two is that it gives you some flexibility in placing lots of data changes all over a page.

But it also has a large downside. Design and implimentation of normal AJAX usually means designing with Javascript. Since you’re front loading everything onto the users computer, actually designing and making changes to data means not only do you need to get the HTML right, but also the Javascript or any other parsing agent you use. This greatly adds to development time and makes maintainability a challenge.

Instead I chose to go a different route, something more in line with the AHAH (Asynchronous HTML and HTTP) method. AHAH could be thought of as a subset of AJAX. There is still asynchronous data exchange, the difference lies in the fact that the data parsing is done on the server and spit to the browser as fully formatted and designed HTML.

This saves a ton of time on coding and mainenance. And given that we’re already using XML/XSLT processing on our servers here at the Walker, it keeps our design process the same as well. Now I don’t have to worry if a display bug is because of badly written HTML or badly written Javascript, I can just design and build the way I normally do and have the page pull in predesigned HTML for the browser to render. It also alows others in our department to update and change the look and feel of our site without having to weed through a bunch of frontend Javascript programming to do so.

This does however make the data slightly less flexible. It’s harder to pull out one tiny bit of data to display in a remote spot on the page (though it still can be done). Our servers are also doing a tad bit more work (however most of the server work is generating the XML from the database, which would happen with either solution). But from a time, maintenance and budget standpoint it’s the right approach.

There’s still a few kinks to be worked out on the Art on Call page, as well as new features to add. These will be available in the coming weeks and should greatly enhance the usability and features of the site. And because we’ve taken this modified approach to AJAX, we’re able to deliver these features in a timely manner.

More on that and some things to watch out for when coding AJAX at a later date.