In my last travelogue entry I concluded that having an application facade instead of coupling the user interface directly to domain objects (or even the database) always seems a good idea when it comes to enhancing, changing and testing an application.
Let's look at a very simple example to demonstrate the basic principle. Consider an application that will search for books when given a search string and display the results. A UML diagram of the facade and the book class looks like this:
All the details of how the search is actually implemented does not interest the user interface (developer). All the graphical part of the application has to do is grab the search string (e.g. out of an input field), invoke the searchTitles method and present the resulting list of book objects to the user in whatever way it wants to.
This kind of application facade is called an Presentation Model. The View, i.e. the presenting part of the application, pulls all information it needs from the presentation model and sends all changes made by the user back to the model in return. There's one additional complication, though. Since the view won't realize a change in the model's state it must either poll for updates in regular intervals or register itself as an observer of the model:
On a model change the view will be notified (changeOccurred) and can thus ask the model for the updated data. That's basically all you have to know about presentation models - for now, at least.
There's another specialization of the facade thingy, called Model View Presenter (MVP). The supporting idea behind MVP is for the GUI (alias view) to do even less, just signal all user input to the to the facade (alias presenter). The presenter will then invoke methods on the domain objects, deciding afterwards about how - and if at all - to change the view. When distributing responsibilities that way the class diagram looks slightly different:
This kind of separating view from application might look more involved than a straightforward presentation model. Nevertheless, it comes with a couple of advantages:
The last two arguments got me hooked eventually. In distributed applications not polling means preventing unnecessary network traffic. Moreover, Ajax communication is asynchronous by definition; therefore MVP is a good fit when we run the view implementation (BookSearchDialog) in the browser and the presenter implementation (BookSearcher) on the server.
What I'd like to do (and not do) in Ajax-driven application development is:
Starting with this list of how I'd like to work, I scanned a few dozens of frameworks like Prototype, Rico, DWR, Dojo - to name just a few. None of them did what I wanted, i.e. none of them provided information that made me think they did. I must confess though, that I exclusively focused on those which use Java on the server.
Enter JayJax, the yet unknown little Ajax framework...