Developing Flex RIAs with Cairngorm microarchitecture – Part 3: Architecting the View

Architecting the View

The first and perhaps most important thing to understand about architecting your view logic with Cairngorm is that Cairngorm doesn't actually care how you do it! One key value of the Cairngorm architecture is that it is lightweight and places little imposition on the Flex developer, so as not to stifle individual technical flair.

Rather, Cairngorm offers clear integration points between the "rich" and the "application" in RIA.

The user interface must represent the application's current state by displaying screens and rendering the model in a specific way. This can include showing the products in Cairngorm Store as graphic thumbnails instead of tabular data, deciding which subset of the products to make visible based on a slider that specifies a product price range that the user selects, or recognizing that the user has finished shopping and guiding them to complete the checkout process. You make decisions on the dynamically rendered views by integrating the view with the model. This is done, in part, with Value Objects and the Model Locator pattern; we will discuss the final piece of the puzzle below.

A rich Internet application enables effective communication between the user and the application. The best form of that communication is bidirectional. While the user interface must "speak" to the user by rendering the view according to the state of the model, it must also "listen" to hear what the user wants to do with the application and respond accordingly. In this case, user requests are called gestures. When users click buttons, drag objects, complete and submit forms, and so on, they are gesturing to the application to indicate what they want to do. Responding to user gestures (by listening to the user), doing something on behalf of the user, and then "speaking" back to the user by updating the view (or, more correctly, updating the model, which you might now recognize automatically updates the view) becomes the flow of conversation between user and RIA. Later in this article, we'll explain the Cairngorm design patterns and architecture that can mediate the conversation between user and RIA.

Also in this article, we'll complete the discussion of the Model Locator pattern by explaining how you build the view to take advantage of data binding in the Cairngorm Store.

Next, even though Cairngorm does not prescribe the view, we'll offer some advice on best practices for structuring your view. You can use much of this advice even if you're not using Cairngorm. If you are using Cairngorm, however, heeding this advice will help you make architectural decisions about your MXML components.

In Part 4, we'll introduce you to a "microarchitecture within a microarchitecture," called the Service to Worker concept. Service to Worker is a collaboration of design patterns that the Adobe Consulting team first advocated within Cairngorm as a way to mediate the essential conversation between the user and the application on a feature-by-feature basis.

Page 2 of 4

Previous Page

Next Page