Flex:: Introduction to Cairngorm

Cairngorm, a really nifty Flex framework that I use quite often at work, with my company, and therefore would give my highest recommendations for it to be the enterprise-framework of choice for Flex developers. Adobe identifies Cairngorm as a micro-architecture that addresses key issues through best-practices in the areas of (1) handling user events in the front-most layer, (2) arranging and managing business logic elegantly, and (3) consistently managing state on the client-side. That is, unlike traditional web-development situations, RIA and Flex in particular is more stateful. [ad] 1. Value Objects Part of keeping the promise of having a stateful application, Cairngorm has borrowed a concept from J2EE, Value Objects or Transfer Objects, which are passed across various layers of our application, in a decoupled way. The following is an example of what a VO looks like :

class com.doronkatz..application.vo.CarVO
implements ValueObject, Comparable
{
        public static var registered:Boolean =
 Object.registerClass( "com.doronkatz.application.car.
vo.CarVO", CarVO ); 

        public var id : Number;
        public var make : String;
        public var model : String;
        public var year : Date;
}

The value object is connected through to the front-layer UI through a concept called data-binding leaving objects to act as source and destination, so if changes are made on one side, it is updated for the other side (i.e updating a text box updates the value through live binding). This is more commonly evident when we play around with Data Grids. The diagram below put's the VO and binding in context. We will explain the rest of the diagram, bit-by-bit. [ad#Adsense]

2. View Layer The view layer, or the front-most layer contains the MXML Views. The users interact with this part of the application, which contain Data Grids, buttons and text-boxes. The Text-Boxes are binded to the Model Layer (to be discussed below) which in turn binds to the Value Object. Clicking on a button for example in the View layer could trigger an Event which in turn uses the Cairngorm process to get to the Controller layer, which chooses the best Command to proceed with. 3. Model Layer The Model layer sits next to the View layer, and acts as the single state-manager for the application, and this is a Singleton (single instance of Model Locator). The model pretty much stores arrays, variables of different types and sorts to keep state. A shopping cart basket contents would be an excellent example. 4. Controller Layer The Controller layer contains the commands that the events would trigger, from the View Layer. It also contains the Business Delegate which will discuss shortly. The commands are enlisted by the events, and are basically classes that do the functionality part of the application (the methods sit here). The results of the command get persisted in Value Objects and the Command objects update the model properties. Some of the commands could enlist the Business delegate, if for example, you have a Web Service or use Blaze and need to interact with objects in other langauges, such as J2EE. This can also be categorised in the Service Layer . In work I mainly use it for SOAP messages to Web Services and could also be used for XML communications. Most important thing to remember in this interaction thing, the Business Delegate passes reference to the Command's 'onResult()' method (or onFault() if we get an error back).

This is it for the first introduction. I will go into each of the components with code samples in the next article.