There's been a lot of discussions lately about the various GUI patterns and their implementations by Flex architecture frameworks, Cairngorm and PureMVC in particular.

I think that this topic is absolutely essential to cairngorm since this framework has often been criticized (including by me) for its lack of proper mechanism for managing the presentation layer.

Some Adobe Consulting team members have praised the use of the Presentation Model pattern for cairngorm applications. Borre Wessel mentionned it during some of his presentations, and Paul Willams blogged about it in a series of posts dedicated to Presentation Patterns and Unit Testing.

However, despite many requests (especially in the blog posts comments and in the Flex coders list), we have yet to see a concrete implementation example of this pattern in a cairngorm application.

On a side note, I know that some will say that's this is typical of the Adobe Consulting / Cairngorm team. We all know (and so does Steven Webster) that they've not been very good at communicating on their framework so far - an area where PureMVC's Cliff Hall has been absolutely great. I think many reasons explain this (AC probably didn't expect such a success in the first place) but that's not the place or time to discuss this. All in all, we have to keep in mind that things have started to change. The open source initiative is a great move, and we can hope the best for cairngorm 3.0.

So rather than wait and whine about this (which I'm usually very good at), I've decided to take the risk and share my views. This post does not pretend to define the best practices or guidelines of such a Cairngorm + Presentation Model implementation. It's just a proposition, in the form of a small application I wanted to share in order to start what I hope to be an open discussion on the subject.

I don't want to get into the whole theory around Presentation Patterns here. You can read Martin Fowler and Paul Willams posts if you want to dive into this. Au contraire, I'm going to try to be very pragmatic.

Why should we care ?

So to put it in a nutshell, some of the reasons why we need a Presentation Layer in Cairngorm applications are :

• Our views tend to be too smart as we often put some presentation logic in it. For example, navigation logic (Browser management) or i18n.
• The temptation is also great to put presentation data in our Models / ModelLocator (think String consts for view states, for instance)
• Unit testing views is really not great.

So the whole idea is to have a new set of classes responsible for encapsulating the presentation data and logic, separated from the concrete view implementations (that change a lot, as we know).

-"Great! Yet another bunch of classes! As if my application wasn't complicated enough !".

Well, as we'll see, the pattern may facilitate some other parts of our application. Moreover, Borre Wessel's presentations introduced (or reminded us) some cairngorm techniques and best practices that I will also try to implement in my example. Our goal is to make our cairngorm applications both simpler and better.

Okay, so this new layer will be separated from the views, but it also needs to be closely related to these views. So the question is : what exactly is the nature of their relationship? In other words, what presentation pattern should we apply?

For various reasons I won't discuss here, it seems that Paul Williams (and Adobe Consulting) chose the Presentation Model pattern.

A Presentation Model for our views

What this means is that we'll have (more or less) one PresentationModel (PM) class for each view. This class will not deal at all with any view class or rendering logic. It won't even know about its corresponding view. It's the view that will know about its presentation model.

So our PM will store presentation data and logic. For example, this includes :

• the String constants that represent your view states
• logic that will switch these states
• BrowserManager communication
• flags that say if this or that part is enabled / disabled
• some string validations
• ...

It is sometimes said to be an abstraction of the view. What this means is that it will never have to be aware of any concrete graphical implementation (rendering data and logic). This stays in the view. In fact, I think that's the only thing that will stay in the view. As Paul Williams notes, this includes animations, dragndrop, and other things that are too closely related to the framework.

Since it knows it, the view can observe its presentation model, and update accordingly.

Now, knowing this does not tell us much about the way we'll deal with those presentation models in our cairngorm applications.

The firsts questions that came to me were :

• How do we instanciate PMs ?
• How do the PMs and the so called domain Model are related ?
• Are PMs decoupled from cairngorm ? 
• Can PMs communicate with each others, and how ?
• Can we use PMs to deal with logic previously handled by Commands?
• Can the commands talk back to PMS, and how?

These are some questions we'll try to answer in the second part of this series, with an example.