About Cairngorm, Mediators and PresentationModels

I'm going to talk about the characteristics that, in my opinion, make of Mediators, a concept borrowed from PureMVC, a better choice than Presentation Models when facing the need of moving framework code out of the view, in the development of real-world Flex Rich Internet Applications. However, Presentation Models fit better for unit testing so, where to go?

Although the most of this write is based in opinions from different specialist from both sides, I'm not speaking from the certainty so I encourage you to criticize me and propose a better approach. I'm not putting source code here, you must follow the link for the referenced example applications in order to access the source code.

When looking for information about Cairngorm and the "major Flex Frameworks on the market today", big chances are that you reach this great article from Tony Hillerson: FrameworkQuest 2008.

Actually, it's a series of articles, each focused in one framework among the following: Cairngorm, PureMVC, Swiss, Mate. At the end of the series, Tony shares their thoughts about each one, specifically about Cairngorm he said:

"problem people have is that Cairngorm has you putting Cairngorm events on the view. That means you have to make a Cairngorm event, first, and second it means that you have framework code on the view that makes it hard to refactor away from Cairngorm.
(...)
What PureMVC tries to fix, though, is having the view cluttered with PureMVC code. It fixes that well - the only place you have to put PureMVC code is on the root application. As far as that goes, I like using Flash events instead of Cairngorm events. What’s nice there is that if I’m using a blackbox component that emits Flash events, I can still easily respond in a Mediator whereas in Cairngorm I’d have to catch and re-dispatch an event as a Cairngorm event if I wanted to take action".

Alistair McLeod replied stating that:

"View specific model information is stored on PresentationModel objects.
We also wouldn't hold view state on the ModelLocator - we store that in the Presentation Models that are responsible for a particular view.
(...)
I presented on Cairngorm in Max Milan, sharing Adobe Consulting's best practices in its use, and discussing the Presentation Model pattern which address many of the misconceptions on the use of Cairngorm, such as those you have mentioned in your comments above".

You can see Alistair's presentation here. Specifically in slides 17 to 19, he introduces the Presentation Model (PM) concept and its advantages for unit testing because there are "no dependencies of the underlying Flex framework classes". Sounds good, isn't it? Per Alistair recommendation, the PM should contain "as much view code as possible", although "User interface logic is kept in the view: anything highly graphical or tied to underlying Flex framework, eg, animation, drag and drop".

What concerns to me is this last phrase. What percentage of the view, in a real-world Rich Internet Application, is not really expected to be highly graphical or tied to the underlying framework? Instead of no dependencies we should say no 100% dependencies. What's the number if no 100%? It depends of the application but for sure it won't be 0%. What if a RIA application relies on animation and drag&drop functionality the most part of its user interface? How unusual is this?

In such a scenario, I don't see a clear advantage on using Presentation Models instead of a similar concept borrowed from PureMVC: Mediators. Even in a normal situation, where we are able to clean most of the framework code out of the view, I'm still concerned with two points:

1. the cost of use of Presentation Models.
   
2. the idea of relying on Binding as the unique way of notifying the view about changes on the model.

Paul Williams covered the Presentation Model is his series of Presentation Patterns. After looking at the source code of the example application, I was amazed by the need of having one method, in the PM, attached to the onchange event for every single edit box in the user interface. I think it turns very difficult to follow the application flow, even if we're talking about a very simple application.

Other key points are:

• Validation: Paul states that "in a presentation model application the validation logic belongs in the model class. I've often felt Flex Validators are a little cumbersome to use from ActionScript code, so I haven't used them in this example". So, how fits validation in the Presentation Model?
• Duplicated VO instances: at the Presentation Model level there is no way of referencing the UI controls that holds the data while it is being edited by the user, therefore another instance of the Value Object is used for this purpose. I don't feel very comfortable with the idea of maintaining duplicated instances.
  
• Graphical logic stays in the view: as mentioned before, some logic stays in the view. That's the case of the 'Abandon Changes' alert box handled by the AlbumBrowserView. Even if "the displaying and hiding of this alert box is still driven by state changes in the model", my doubt is: what if the application were a little more complex?

In the Comments section of this article there is a question posted by someone identified by Sholomi that remains unanswered: "the examples are simple , where do you write the code when the application get really big and ugly".

I looked for the answer in the Cairngorm Forum without lucky. However, there is an interesting post about Communication Throughout Application and Components where you can read the following from Peter Lorent: 

"In most apps I use PureMVC and I guess the main reason is the Mediator. This class is loosely coupled to a mxml (most likely) component by way of a reference. The Mediator registers event listeners with the framework for the events it's interested in. And when receiving an event acts by using the API of the mxml component. The mxml component only dispatches events to the Mediator and the Mediator then decides what to do. Today I needed to do a client change on a running app and the only thing I needed to do was modify a Mediator to listen for an event that was already broadcasted and add a public function to its mxml component. In every aspect I can honestly say that an event driven app is in my point of view the way to go".

To my understanding, the "even driven app" is one key when comparing Mediators vs Presentation Models. In the former, you have one single entry point (the notification handler) so you can follow the application flow in a way you can't do it if you have to go through all those onchange handlers in the Presentation Model.

The other key is: Data Binding. As I noted earlier, I'm not happy with the idea of being reliant on Binding as the unique way of notifying the view about changes on the model. Like Tony said: "I think binding is good when used responsibly, so when PureMVC says to skip it, I’m interested, but I want to know what it costs to use. So what I don’t like about PureMVC is how much boilerplate code there is. I like the idea of a mediator for views, but there is so much set up to do".

That's why I like Cairngorm: is simple, there is not so much setup to do. Once you get the idea, is very simple to add a new functionality to an existing app using Carngorm, as demonstrated in Developing Flex RIAs with Cairngorm microarchitecture – Part 6: Rapid and consistent development with Cairngorm and Flex.

So, what if we could use Mediators in Cairngorm? Sure thing the idea is not mine, it was very nicely implemented by Anirudh Sasikumar in FxStruts: Easily Fit a Flex Frontend to your Struts Application. Obviously, the primary aim of the article is to demonstrate the use of the FxStruts library by means of an example application: Flex Struts Mailreader.

Arinudh has used Cairngorm for building the Flex frontend, but he went one step further. In the walking tour we can read: 

"There's also an interesting bit of addition to the normal Cairngorm architecture in this application. The view 'Mediators' borrowed from PureMVC. Each view has a Mediator class that can listen for event notifications from the model and update only that particular view component. This was added to plug the inadequacy of having to use Data Binding all the time for notification of change in the Model".

I would like to remark the last phrase: the inadequacy of having to use Data Binding all the time for notification of change in the Model. Even if I use Presentation Models to take the framework code out of the view (with a certainty that some percentage will remain in the view because is highly graphical), I'm still relying in Data Binding all the time!

I think Data Binding is wonderful, but for sure it turns into a problem when abusing of it. That's why I believe Observer patterns, like Presentation Model, are not the best option, although I like the idea of Presentation Models being easier to unit test. What if I could have Mediators inside Cairngorm that were easier to unit test? One thing is true: we need something. If not Mediators, something else that solves the same problem, not only a part (of a part) of it.

Finally, another thing I like of Mediators is they belong to PureMVC, they belong to the framework. As of now, Presentation Models don't belong to Cairngorm, they are suggested as a best practice. Therefore, whatever the solution found, should be incorporated into the core of the framework.