My Not So Private Tech Life

Today it's not about software. Today it's about violence. My violence.

Do you have kids? Imagine yourself sitting on a bench in a public children's playground watching your 5-year-old offspring climb whatever seems climable to him. There's also a bunch of older and unattended children who are constantly stretching the limits of what you consider to be the appropriate kind of game on such a place, like throwing around pointed sticks and shooting each other off with a leather ball from a one-meter-distance. You remain perfectly quiet and peaceful; after all, you're not in charge of the lot nor the playground.

Dog poo enters the scene. Dog poo that's being transferred from the bushes outside the ground onto the ground by the supposed-to-be leader of the group. It's being thrown around on sticks and distributed over the place.

Now you start feeling responsible. Neither do you want to step into flavoursome excrements nor do you want to watch toddlers feeding each other sh..! So you get up, walk over to the boy-in-charge and request (well, tell) him to clear away what he so boldly dared to procure. He's very clear about not being in favour of your wish and continues with whatever he did before you disturbed him.

Here is my question: What is a proportionate means to show a youth the limits of publicly accepted behaviour and when do you cross the line towards violence against someone so much weaker. Would you grab the boy's ball announcing that you're gonna give it back as soon as cleaning up will be finished? Is it okay to rub the ball into the stinking mud to inflict upon the boy what he was willing to inflict on others? Perhaps you would leave the playground including your son and the ball - committing minor theft - just handing the boy a note where his parents can contact you?

To be frank, I don't have anything close to the right answer. From hindsight, though, it is obvious to me that I definitely had stepped beyond proportionate sanction when I found myself struggling with a 10-year-old who was clinging to my bag because it contained his ball. Eventually, I gave in when a man watching the scene threatened to call the police since it was his "duty to act when a kid is obviously suffering."

Well, I've felt baffled ever since about the discrepancy between acting responsibly and acting in a disproportionate and violent manner. Even though distorting Paul Watzlawick's famous sentence, I believe that one cannot not be violent - not when living in a human society, that is.

So maybe all that is a little bit about software development, too. I can remember times when my intention to pursue a allegedly good goal, i.e. being a responsible developer or team lead or project manager, made me act in ways not compatible with the most important rule of agile software development "People over Process". Disregarding and disrespecting the humans involved in our projects is violence.

Johannes

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.

Presentation Model

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.

Model View Presenter

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:

• It's as good as you can get in removing all logic from the actual dialog implementation.
• By stubbing the view you can test the application logic plus parts of the presentation logic without actually going through the real user interface.
• The view does not have to poll the facade or pull data from it. Everything is being pushed onto it.
• The communication that takes place between view and facade is almost perfectly asynchronous. Most (or even all) methods in the presenter interface do not have return values and all the presenter does to the view is sending messages about how to change display state.

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.

Programming Model of Choice

What I'd like to do (and not do) in Ajax-driven application development is:

• Define the presenter interface (e.g. as a Java interface), implement it on the server and have a proxy for it on client-side, which can be accessed in a very easy way, e.g:
  searcher.search('.*AJAX.*');
• Define the view interface (e.g. as a Java interface), implement it on client-side using JavaScript and have a proxy for it on the server. Usage should be as simple as:
  searchView.displayList(listOfRetrievedBooks);
• The translation of calls to the facade into XMLHttpRequest objects and dispatching all resulting calls to the view should happen behind the scenes and not bother me as an application developer.
• All (un-)marshalling and (de-)serialization of message calls, invocation results, exceptions and data transfer objects should be done automatically and not further strain my age-stricken set of grey cells.

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...

Johannes

Are you looking for an online tutorial on Asynchronous JavaScript And XML? This is not the place for you then, but Max Kiesler's round up of Ajax online courses might be. Nevertheless, before reading on you should be aware of what AJAX is all about. Here's the quote from Jesse's original paper:

Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

• standards-based presentation using XHTML and CSS;
• dynamic display and interaction using the Document Object Model;
• data interchange and manipulation using XML and XSLT;
• asynchronous data retrieval using XMLHttpRequest;
• and JavaScript binding everything together.

Strangely enough, communication via JavaScript's XMLHttpRequest object is - despite its name - not limited to XML contents. You can send and receive anything which can be transmitted via HTTP.

Ajax techniques can be used in a billion ways to embellish traditional flow-oriented web apps. However, more interesting for me is the foreseeable shift to web-based SPAs (single page applications), yet another acronym that tries to manipulate our subconscious mind with its standard English meaning.

As for the connection between domain and presentation logic SPAs resemble much more rich client applications than web apps. One of the more complex decisions you have to make when distributing a program between two computers (the client and the server) is: What code should we have on the server and what code should we develop for and deploy on the client.

On the extreme ends of the imaginable solution space you have the "SOA-infected guys" and the "composable widgets people". The first group advocates to have all integrating business logic, i.e. the application logic, on the client and to only invoke application-independent "service calls" on the server. The latter crowd even compose the user interface layout on the server - usually doing some JavaScript generation behind the scenes - and wire the individual widgets living on the client to their counterparts on the server.

Personally, I have issues with both ends:

• Building user interface experiences with Html, CSS, JavaScript and DOM does not lend itself very well to the composable widgets perspective. Moreover, the tight coupling between client- and server-side widgets leads to high-frequency communication; in many cases this communication is conceptually synchronous.
• "Just" calling services and aggregating their results into application-specific behaviour, however, requires that you have (at least large parts of) the domain model available on client-side, i.e. you have to do some non-trivial mapping from your server-side language to and from JavaScript. The generic kind of services often delivers more information than actually needed for display, thus bandwidth becomes more of a problem. Additionally, interpreted JavaScript is not fit for large amount of computation.

So, I decided to search for an approach that allows me to have all *presentation* logic and code in the browser but all *application* and domain logic on the server. As a surplus gift I'd get testability of application logic for free! I didn't have to look for long, though. Hiding all application logic behind an application facade has been my favourite architectural refactoring for years. There are two basic forms of application facades (see e.g. Martin Fowler's presentation patterns):

• Presentation Model
• Model View Presenter

Common to both is their strong ambition to decouple user interface from logic. And both can - in theory and praxis - be used for Ajax-driven SPAs...

I hope that's enough of a cliff-hanger to keep you tuned.

Johannes