BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Comparing GUI Patterns in PureMVC and Cairngorm

Comparing GUI Patterns in PureMVC and Cairngorm

This item in japanese

Bookmarks

On June 9, 2008 Per Olesen, a seasoned Java developer, published a blog post on Tech Per to comparing the two most popular Flex frameworks, PureMVC and Cairngorm, in particular with respect to usability and how they apply patterns of GUI architecture.

Design pattern-based application development has been a mainstay of Java developers for some time. Among Flex or ActionScript developers, this practice is either carried from Java development experience or introduced by a few ActionScript/Flex frameworks. Olesen describes this process as follows:

To help architect such applications, some patterns on GUI architecture have been developed and described. Martin Fowler has some good descriptions of some of the more well-known, like Presentation Model and Supervising Presenter. These are not whole user-interface (UI) architectures, like MVC, but smaller parts of architectural guidance, related to how the logic of the application relates to the API of the view framework.

He explains:

PureMVC has a construct called a Mediator, which is just what it sounds like: an application of the Mediator pattern, to mediate between the apis of the view and the apis of the rest of the application. This is a key construct in how PureMVC implements the view part of the MVC architecture and is introduced to reduce the dependencies between the application and the view, thereby lowering the coupling in the entire system.

Olesen also points out that PureMVC has a document on implementation idioms and best practices that provides an actual example, the LoginPanel. In the example, it shows that only the mediator knows about the view, and that the view does not know about the mediator.

Upon analysis of the source code provided in PureMVC's document, Olesen believes this pattern is what is known as either a Supervising Presenter or a Passive View. These patterns both extract behavior out of the view and into a presentation class coupled with the view. In both patterns, this is done in a “presenter knows the view, but the view does not know the presenter” way. Thus, what differentiates these two patterns from each other is how much logic to extract. Therefore, the PureMVC mediator comes closest to being a Supervising Presenter.

With respect to the Cairngorm framework, Olesen observes:

Cairngorm has no notion of a mediator, a supervising presenter, passive view or anything like it. Actually, it has been bashed by many, as it advocates a solution of simply data-binding of view component state directly into the model. And, to make matters worse, the model is simply a global state, expressed through a singleton.

Looking at the Cairngorm documentation and the examples (both the introductory contact management app and the “advanced” Cairngorm Store), only make this stand out even more. The views have lots of logic and as such operate as what is known as the Autonomous View pattern. So, what is an autonomous view? Martin Fowler describes it as: Putting all presentation state and behavior for a window in a single class.

Olesen thinks this is like having a “no pattern" pattern. He believes that the autonomous views in a Cairngorm-based application are advocated to databind directly into one global model instance, and it makes for really bad separation of concerns between the view and the model.

In the end, Olesen doesn't simply think one of the frameworks is better than another; he concludes:

The UI pattern is just one part of both frameworks, albeit an important one. One could argue that you get more out-of-the-box with PureMVC, the mediators being a built-in concept of the framework. The mediators and the communication from and to mediators through notifications have been nicely worked into the PureMVC framework.

Rate this Article

Adoption
Style

BT