Wednesday, December 21, 2005AJAX Diary: Our first 100% AJAX application
We've just finished a complete rewrite of our CRM user interface using AJAX. The whole thing was written using Object-Orientated JavaScript, and has given us a 10 fold increase in responsiveness. As usual, we didn't use an existing framework, but rolled our own MVC framework.
The backend business logic was left untouched, and a facade layer was created to translate client requests into calls to existing methods.
I thought I'd share some of the things that we implemented and learned whilst developing the interface. I will be also publishing followup posts over the next month or so with other tidbits of information.
Batching and caching
We built a communications layer that optionally allows us to cache and/or batch requests. For instance, if you pass the "account cache" object a number of account codes, it will go and get 25 at a time from the server, and the cache the results for a predetermined length of time. If you pass any one or more of the same codes again, then it will not go back to the server.
We implemented this style of batching on our search results system. When you filled in the criteria form, and clicked the submit button, it would send a request with the criteria and then get back a list of account codes that matched it. These accounts we then fed into the "account cache" object, and the information about each account was retrieved. The results we then shown to screen as each "batch" was received back from the server/locally.
One of things we found was that there was very little difference between getting one or 25 records from a database at the same time. In fact, most of the time was ColdFusion's startup and shutdown!
Events & Listeners
One of the most common problems when developing a user interface is keeping it suitably decoupled from the model, and indeed, from other user interface classes. We found that building an event queue to be an elegant solution. User interface objects listen for events that get fired by other UI objects, controllers or even the model. This way, you can very easily build two entirely different views for the same model.
As an example, we had two "pods" in our interface that displayed "groups". The first pod showed a combo box with a list of groups in it. The other showed a tree-view of the same group list. Each of these views listened for the "groups retrieved" event, and re-populated themselves with the group data contained within the event message.
Frameworks such as
DOJO have implemented this, as we found out later ;)
In my next post I will go into request brokers, serialisation and JSON instead of XML. I'd love people to share their own experiences building DHTML / AJAX user interfaces.
where's the application or a link to the application??
yeah, let us see.
it's an internal application, so I can't provide a link! I'll see if I can get a screenshot or something.
Did you find that using AJAX/XML is slow compared to using AJAX/Plain text?
That's interesting that you used the event queue like that. I did the same thing when working in Flex 1.5. All of my backend and UI pieces communicated through an event manager which triggered handlers registered centrally whenever an event was fired from anywhere.
Yeah, an event queue is an elegant way to program. It really opens you up to possibilities that weren't there before, and is *extremely* scalable. One of the Java guys has even implemented an applet that can communicate with a JMS and call JavaScript code in the parent document (not part of our system, yet). Now that is cool.
would definetly like to exprience the application.. Can you give us a demo link??
I wish I could. I might be able to put up a screen shot or something if my boss lets me. It is a financial industry CRM, so the information within it is pretty sensitive.
»