AJAX response handling
October 11th, 2005I’ve come to really enjoy dropping some AJAX in my web applications. It’s added a new dimension to several of my products, and I am finding myself using this little combination of technologies more and more. There are a handful of problems with AJAX, most notably the back button issues, but to me there is a broader consideration about when to use AJAX.
little note: I’m not going to get into AJAX implemenation here, webpasties is a great resource for that.
The problem
When you use AJAX, you are using javascript to interface between the browser and whatever action you are taking. In general, it goes a little something like this:
One of the things I like about AJAX is how that server-side script is it’s own little entity. It makes it easy to reuse a common bit of code through AJAX. Very tidy.
But at the moment I’m concerned with step 6. When the server-side business is done, it returns something to the browser which is captured in the javascript. So far so good. You’re data is back to the browser without a refresh. Cool. But now, how do you handle the data?
I’m going to break down step 6 into the two options:
6a - responseXML : The stuff from the server can be formatted as valid XML. Now that you have a sweet bit of XML, you can throw together an XSL and do a client-side transform. Or, you can take that XML, and crawl it using the DOM, and get what you’re looking for.
6b - responseText : The stuff from the server can be formatted as simple text (comma delimited or whatever you fancy). Then you can take that string, parse it, search it, whatever-it, and display the stuff you care about.
So here’s my problem: with either responseXML or responseText, you end up with extra files or laying a lot of html in the javascript. Either way, the page is harder to maintain and edit. Let me be clearer: with responseXML, you have to either have and XSL file (a new file, adding complexity to large applications). Or with reponseXML or responseText, you have to assemble HTML in your javascript, and insert it into the page. Writing symantic HTML really helps here, but it still requires you to put mark-up in your javascript. That’s just hard to maintain.
The solution
I don’t have a solution. My point is that I think that the above problem should be one of the biggest considerations when deciding whether or not to use AJAX. It’s a very practical problem that nobody seems to mention.
In discrete applications (like google’s mail app) it makes sens to have a single screen, and do everything via AJAX. If you do this all of you mark-up is either based in XSL, or is mashed into the javascript. It may get a little messy but at least it’s consistent.
I’m more concerned with very large applications (the kind most web developers eventually work on, not just little boutique sites). In large apps, you’ve got dozens of directories with hundreds of files. Adding an XSL (or many XSLs) for individual pages gets real messy real fast. Putting mark-up in javascript makes things really hard to maintain, especially with multiple developers. The question “I clicked on that link, and it displayed drill down data - where did the layout of that drill down data come from?” becomes very difficult to answer.
The question
Has anyone come up with a nice, tidy solution to this? I like the “discreet-task” nature of AJAX, but I don’t like how much content gets handled in Javascript. As a result I tend to think the XSL solution is cleaner… but I’m starting to get tired of all these little XSLs sitting around. Am I using AJAX when it’s not appropriate? Maybe, but if so, then AJAX doesn’t have much of a place in a really large app… and that’s just no fun.
Hi, this is a really good question that I asked me several times.
I don’t see any “clean” way to do that at the moment. I am working with xsl most often of the time but I am a bit tired with the mess it generates in my files.
We could imagine a javascript toolkit with rendering methods that generates html. We load our xml response in the toolkit and we programaticaly build the interface in javascript by calling our methods with xpath strings as parametters. myUItoolkit.renderSpan(’/user/details/@firstname’);
This is just an idea and maybe far from being a good solution.
This is an interesting idea…
So a series of methods that render html element(s).
In my javascript I tend to build HTML objects via the DOM, which takes several steps. Your idea might move those steps back a layer… I like that. What about assembling the final pieces? (so if I’m displaying a list of 10 items, I have to build the 10 items, then define them as siblings.) That still takes some work..
I like the idea though. A generic library of “html builders” (that works cross browser) might go a long way here.
The thing would be to handle lists or any repetitive task into a single method in our “html builder”. For example, we want to display a list of users. Here would be the response from the server.
<users>
<user id="1" first-name="john" last-name="smith"/>
<user id="2" first-name="mike" last-name="brown"/>
</users>
We would then have a method renderTable() that would get an xml element as parametter (instead of an attribute) and parse all child of this element as table rows.
var myPattern = '<td>@id</td><td>@first-name @last-name</td>'
myUItoolkit.renderTable(’/users’, 'element', myPattern);
This would generates a table and rows for each user element following a specified pattern.
We could imagine the same with renderDropDownList() or anything we want in fact.
I think that building such a toolkit would be a big work but once done, it could be a great tool to handle xml responses.
Nice article, hopefully you solve your issue.
…and what if you just do the markup on the server? Like the live search thingy you see everywhere nowadays? Spits out a nice bunch of li’s (which is perfectly valid XML) which is just thrown into some other element. That might feel messy, but IMO it’s way cleaner than doing all kinds of markup at the client — to me, that is to be avoided at all cost. Manipulating the DOM to create the needed elements on the fly seems like the cleanest option to me, but I wouldn’t use XML as an intermediary (sp?) — way too much overhead. I’d go for something like JSON.
…but that’s my slightly-more-than two cents =]
You should have a look at Nevow Athena (was called livepage or liveevil depending on how far you go back). It does what Ajax does but in both directions with a bit of added zing. MochiKit also implements Stan tags in javascript (Stan tags are part of Nevow also). Running in a Python process near you…
Max: “and what if you do the markup on the server… bunch of li’s”
I like this idea, and I’ve started doing a bit of this recently. But I still struggle with maintainability. Another developer comes along, sorts through a page, and inevitably says “where’d those li’s come from.. [10 minutes of investigation].. ooh, that OTHER jsp/asp/php”
I agree that the code is a lot cleaner (I’m totally with you, much better than client side manipulation) but it still doesn’t feel quite right. I end up with front end code in server-side code… gotta be a better way (?)
Tim… I’ll have a look…
I’m a bit late to this but in the summer I was re-designing my companies internal telephone directory and after reading about ajax realised I could make it work similar to iTunes i.e results appear as you type.
The backend is MS SQL2000 which uses XML query templates and you can transform it on the server with XSL and pass that back to the client. It all appears to work very fast (altho does run on a LAN) and by using as clean HTML as possible the data sent back is comparable to the initial XML result.
MS SQL is maybe not the most convenient platform but i understand that Oracle can do this and there are Perl modules for the same with MySQL. Don’t think PHP can unfortunately.
However, there are quite a lot of XSL files required. The positive thing i suppose is that they are pretty small and when there is a problem the source is usually easy to identify.
Don’t know if that is good/bad/indifferent - just my experiments so far.
If your main problem are other people, that want to know the markup, that gets generated, then why don’t you write all the markup templates right in the page? It could be hidden first and then edited/copied/used as a draft later by Javascript.
With the help of innerHTML (which feels dirty, I know) you’d only have to replace some text token (in the markup that is already in the page) and perhaps do some element duplicating/regrouping to make the new content visible through JS/CSS.
Of course there is more to load at first and I see a problem with very dynamic pages, where it is imho better to receive generated markup that only has to be inserted into the page without further processing. Any thoughts someone?
Struan - I’ve been using the XML query abilities in SQL 2000 as well - and love it. But all those little XSL files just rub me the wrong way. (I build an application recently that was simple to the user, but ended up with 39 XSL files… just nasty - I was starting to run out of meaningful names for them…)
Graste - the templating idea is interesting, similar to feef’s thoughts above. But I haven’t been able to come up with anything generic enough. I always end up with and exception case which leads to more JS… clunky on top of clunky. But I love the concept.
Most recently I have just been generating html on the serverside, then dumping it in the page with innerHTML. this feels dirty to me, but I gotta say it is easy to develop and easy to maintin (so far). I just posted an example using this technique. (example here, article here).
My jury is still out though - but these ideas are good…
I think that Mochikit http://mochikit.com/index.html has some really good tools to handle xml or json to html manipulations.
It´s a very interesting Blog and simple answer of many questions.
Thanks, i was desperately looking for that info!, great article covering some points I really needed, some good usability info for.
I was wondering how to display the http post response in a popup window? Any suggestions? Thanks
A instructive explanation and a good answer to a problem.
THX
There are many useful informations in this article. Thanks and greetings from Thuringia!
Thanks so much