HomeAjax: It’s not all about XMLHTTPRequest (part II)
In my previous article, I pointed out that XmlHttpRequest is already misused and misunderstood, and that cutting down server accesses is the key for better and faster web applications.
A slightly revisited Ajax Web Application model looks like this (based on J.J. Garrett original article on Ajax)
Ajax Web Application Model Revisited
In this model, the client retrieves the preliminary data and the interface templates from the server. The Ajax engine then takes over the responsibility for running the application. The next server access only occurs to save the final state of the data.
Note: This diagram is not showing asynchronous server access, because I’m trying to make the point that server access is often not necessary in the first place. But of course, asynchronous server access can sometimes be beneficial or required (multi-user functionalities or user authentication for instance).
To fulfill his role, the Ajax Engine must be able to display the different screens of the interface, process the user inputs and apply the changes to its internal representation of the data. Respectively, this involves XSLT, Javascript and DOM.
Managing Data Client-Side
The Document Object Model (DOM) is pretty good at this game. After all, it already maintains the state of your web page. Modern browsers will let you instantiate a new DOM Document that you can use to manage your data. A DOM document it is not limited to HTML but can hold any type of XML data.
Painting User Interface Client-Side
XSL is a templating language designed to be the perfect companion to XML. Applying the template to a XML document is a process called Transformation (XSLT).
XSL templates will typically contain HTML markup for the different pieces of the interface, and several XSL templates can apply to only one XML document, representing the different states of the data through the life of the application.
Support Considerations
The XSLT specification was finalized by the W3C in 1999. XSLT is currently supported by Internet Explorer, Gecko-based browsers (Mozilla, Netscape 7 and Firefox) and will be supported by Safari 1.3.
The technology is definitively mature and supported by over 95% of the current browser market. If you are concerned by the few remaining percents (Opera and other marginal browsers), it is possible to use a fallback solution: Offload the XSL Transformation to the server using a pseudo-XmlHttpRequest.
Sarissa is an open-source wrapper that offers a handy uniform syntax across browsers for everything XML/XSLT and XMLHttpRequest.
Conclusion (updated)
For a practical example of client-side XML / XSLT integration, see the Ajax makeover articles.
April 22nd, 2005 at 8:13 pm
A simple application that could benefit from an extreme makover would be online teacher-created quizes like those found at quizlab.com.
Each quiz is prepared by filling out a series of forms, and there just has to be a way to streamline several parts of the process.
The quizlab people have made their system very complex to cater to a wide range of needs. It may be possible to create a simple version that ends up being more flexible. A good example of this flexibility at the expense of complexity is Basecamp’s project management application. http://www.basecamphq.com/
Other examples:
http://school.discovery.com/quizcenter/quizcenter.html
http://quizhub.com/quiz/quizhub.cfm
May 28th, 2005 at 2:26 am
“The next server access only occurs to save the final state of the data.”
Think that’s a key sentence. Been trying to raise some of this stuff AJAX: what’s a session?.
Anyway - like where you’re going with these blogs.
June 1st, 2005 at 3:38 am
Thanks for your comment Harry, you have a good article over there. That reminds me I need to implement a onUnload handler in the Form Builder to make sure the user has saved his form before leaving the application.
June 2nd, 2005 at 1:44 am
One question that keeps bugging me with AJAX web apps is how to dynamically render UI. Backpackit does it by sending large chunks of html back from the XHR calls, but Gmail returns a minimal blob of javascript (more efficient wire protocol, but more UI built-in the javascript).
In both cases the client-side script needs to be able to incrementally modify the UI. But for your application to support non-javascript browsers, you also need to support re-rendering the whole page (not just sending deltas back). Is there a good approach/framework for handling both without having to write an app twice?
Also, I just posted a Greasemonkey user script that should help debugging AJAX applications in Firefox. Get it at http://blog.monstuff.com/archives/000252.html
Let me know if it helps your development cycle.
June 2nd, 2005 at 1:47 am
One more thought: a number of web apps use asynchronous XHR calls to update the server. This may be more expensive that your “save button” approach, but it’s pretty cool that all your changes get persisted automatically…
June 2nd, 2005 at 2:33 am
I think that a auto-save feature (using xmlhttprequest) is great, but it can also generate some usability issues. What if I want to cancel whatever change I just made ? If I didn’t use the save button I may assume that quitting the application will discard my changes. Removing the ’save button’ altogether can be confusing too..
As for UI rendering, I just love client-side XSLT (I talk more about it here). One benefit of this approach is that you can reuse the same templates to generate the interface server-side if the client doesn’t support XSLT.
I am not aware of any application framework that would handle client-side and server-side interface rendering seamlessly. I also think that most current app. framework are not mature enough, as the recent mess with the Google Accelerator demonstrated.
Thanks for the link to your user script… I’ll check it out.
June 3rd, 2005 at 3:19 pm
[…] go with AJAX, which is suggested in Ajax: It’s not all about XMLHTTPRequest (part I) and part 2 - namely start treating Javascript as a real runtime, occasion […]
June 16th, 2005 at 6:15 am
I have only one problem with this ‘revised’ approach. I do *not* want to write the guts of my app in Javascript, nor do I want to expose my code to the end user. I think JS is great for the UI, but some logic needs to be back at the server.
June 16th, 2005 at 9:54 am
Jonathon, I’d be curious to know your rational.. Not that it doesn’t make sense, there’s plenty of good reason not to write pure javascript web apps. I just wonder what is your (and other web developer’s) primary concern, application security/integrity, graceful degradation, intellectual property/copyright issues ?
June 16th, 2005 at 6:55 pm
The application itself is very specialized. It’s an in-house application so I don’t mind requiring JavaScript being turned on. But the back-end of the app is written in Lisp. This makes it very flexible and is a very powerful language that fits the problem domain very well.
What I’d like to do is set up the JS GUI to handle the display and interaction only. The processing, report generation, etc. will all run as a Lisp application back at the server.
I believe even gmail makes calls at various times to get data, so it doesn’t cache all the messages locally.
June 18th, 2005 at 6:25 am
Thanks for writing such a nice article.
I am using AJAX architecture to automatically refresh data on the page. My application is like this, i have a client which talks with the server and server loads data into the database. As soon as database is loaded to the server, i show it on the client browser. There can be many clients from many location and all of them will be able to see the latest data from the server. So i continuously refresh client page by making XMLHTTP request. To achieve the same i had previously meta refresh but that looks ugly to me so i found this and started doing it. It works well and i am forming my html at the server, how can i only get xml data from the server. Do i have to form xml by myself and send as a string (echo finalXmlFormed as in php). Because by forming my HTML at the server i think i m making this rendering fast and if i create xml string which, then i can use xslt to do render html page. My first question is how can i do this ? Am in thinking in the right direction.
Secondly, making many http request will not harm Apache server? I tried to get rid of ciruclar calling and memory leak in javascript but i am refreshing three frames within a page and each with a time interval of 10, 10 and 5 seconds. Will it be problem for the server i.e. getting many request and stuff?
Any pointer in the right direction will be highly appreciated.
June 21st, 2005 at 2:31 am
Dipesh,
If you only need to display html, form your html server side and send it as is. It’s only worthwhile to send xml if you actually need xml on the client for other purposes, see this article for instance. Client-side XML/XSLT can be also useful if you have different views for the same data.
On your second question, that’s what they do.. Apache servers are meant to handle http requests, so you’re not gonna ‘harm’ the server.. you may overload it, but there’s no way of predicting how many users/requests would be too much.. just test and monitor your server.
June 23rd, 2005 at 5:22 am
Hi,
Thanks for replying and informing me more about proper usage of xml data using AJAX architecture. Highly appreciated.
As I have mentioned in my first post, that I need to refresh client page continuously if something new is inserted in the database. I have partly achieved this by using the following.
Initially i send -1 as last time client updated and server (database) has its last update time. If server time is greater than client time i form HTML at the server side making request to DB layer and getting result. Along with this i send last update time of the server. Now there are chances that my server (database) might have new record or data which needs to be published to all the clients. Now my client has that time and in the client i have used settimeout function to fire http request to compare last update time of the client and the server (database) and cycle continues. This is working perfectly fine with the following two problems :
1) If i keep my page open for the whole day my client will request to server to check whose update time is greater. If server time greater new html is sent back to the client. If it is not great then i don’t form html but only request is made. Now the real problem is I have three frames in that page and each frame does this task, which raised my concerns for the amount of http request i m making even if nothing is happening? Now i have thought of one more idea which is like this: Can i put one more hidden frame which does this and if something happens then it will trigger http request in remaining three frames ? So overall only one request will be send from one page. If anybody has better solution for automatically refreshing client page on database change and would like to share, it will be of great help.
2) Second problem which I see is, as I am forming my html and server side and sending it to the client and to replace it on the client page i use tag and inner html property. But since i am doing this it gives flickering on my client page. I checked gmail etc which are event based and they are really smooth. How can i make this smooth and not flicker?
Thanks for the link to the xml/xslt on client side article.
Thanks again for replying and answering my query.
Cheers!
Dipesh
June 23rd, 2005 at 9:34 pm
Dipesh,
Regarding the flickering issue: When using innerHtml to output content to a page, the browser has to parse the string, build a DOM fragment and append it to the document tree. I suspect it takes long enough to cause the ‘flicker’. If you check out the Form Builder in IE you’ll see that problem also. In Firefox it’s much better though (faster rendering engine?).
I suspect you could improve the situation by using a buffer of some sort. Load the content in a hidden div first (the buffer), and then switch the visibility using css : originaldiv.style.display = “none”; bufferdiv.style.display = “block”;
I have not tried it, but if it works let us know.
July 16th, 2005 at 1:47 am
hi,
Well i have implemented auto refresh with AJAX architecture and its working fine. I have developed this real time monitoring system in other words.
I tried that flickering solution (buffer div tag and making it visible and invisible) but that didn’t helped. I am planning to change all my links from href to xmlhttp? Will that be a good idea to do?
Thanks for your solution.
Regards,
Dipesh
August 30th, 2005 at 7:34 am
It is sometimes better to collect data from the server as you go. I use XHR in our intranet app, and it saves downloading large amounts of data(many thousand products) for use in selects when only a small amount is usually needed(one to three catergories out of fifty). The difference in page load times and response time is very noticable.