Flex: Basic overview of Cairngorm 3 Libraries

Cairngorm 3 was announced as being available last month, with an increase in functionality scope, and some nice draft documents to keep us busy for a while. Adobe Technical Services decided to split the implementation into three specific parts : 
  • Guidelines explaining the motivation
  • Tools to adhere to this guideline framework.
  • Libraries to extend existing architectural framework and solve existing problems.

I am going to discuss the latter in brief, the Libraries to extend existing architectural framework. 

#1 Observer Library
The Cairngorm Observer library provides a set of non-visual components for declaration in MXML that observe other objects, react to changes in some way and execute view behavior. These components can help to reduce the amount of Script-block logic required in MXML components.

We find ourselves when working with Cairngorm, having to find ways to observe and react ot changes in a model object. I have been using mx.binding.utils.ChangeWatcher but with this new library,but for a simple MXML way of binding, we normally do something like:


<mx:TextInput text="{ model.firstName }"/>

 

Sometimes though, such a property might not exist and a developer needs to call a method defined on a view component, so enter Observe

<cg:Observe      source="{ model.firstName }"      handler="runEffectFunction"/>
..
<cg:ObserveValue      source="{ model.firstName }" value="{ Name.SARA }"       handler="runEffectFunction"/>

The second, ObserveValue tag only calls the method handler if the value of the property equals the source, so if the name equals SARA, the observer will be triggered.

Observer and ObserveValue can only listen to bindable properties of models. The EventListener tag adds the ability to listen to events that a model dispatches as the following examples shows:

<observer:EventListener      source="{ model }"     type="{ Person.UPDATE_EVENT }"     handler="runEffectFunction"/>

#2 Popup Library
The Cairngorm Popup library is a small Flex library for opening and closing popups. Instead of using the PopUpManager directly and writing script-block logic to manage their creation and removal, a pair of simple MXML tags are available for declaring within view components. Here’s the “Hello World” of declarative popups:

This simple library is simple in that its in charge of opening and closing popup windows, based on whether the open property is set to true or not, or if you decide to work with the dispatched EVENT.CLOSE event to be handled elsewhere.


<popup:PopUpWrapper open="{model.openPopUp}">    <mx:Label text="Hello World"/> </popup:PopUpWrapper>
...

<popup:PopUpWrapper    
  open="{model.openPopUp}"    
  center="true"    
  modal="false"    
  childList="{PopUpManagerChildList.POPUP}"    
  opening="openingHandler()"    
  opened="openedHandler()"    
  closing="closingHandler()"    
  closed="closedHandler()">    
  <mx:Label text="Hello World!"/>
<popup:PopUpWrapper>

Therefore, this clean and easy approach aims to remove duplicity of code whilst controlling the appearance of the window through bindings.

#3 Task Library
Events are fundamental to Flex. Every component in the SDK dispatches an assortment of them, while application developers regularly create their own to represent user gestures and other significant occurrences. With so many events being dispatched and handled, coordination can become challenging. A class may assume too many responsibilities, such as initiating an asynchronous service call, handling the result, then triggering a subsequent service call and handling that result also. 

A general task-processing library has been introduced to ensure the asynchronous sequencing of tasks are performed orderly, whether concurrently or queued according to dependencies, with indicative events to portray the progress to higher-level components.

#4 Validation Library
The Cairngorm Validation library is designed to simplify validation of user input and other data. Instead of declaring validators individually in MXML and coordinating them manually, a group of validators can be defined using the ValidatorGroup component. The validity of the whole group can then be determined as one. Validator groups can be detached from the view and applied to other layers of an application, such as a domain model. Additional components are provided for observing validation rules and updating view components to highlight validation errors.


<validators:ValidatorGroup id="validatorGroup">
        <validators:validators>

            <mx:StringValidator id="firstnameValidator"
                source="{ firstnameInput }"
                required="true"
                minLength="3"
                property="text"
                triggerEvent="change"/>

            <mx:StringValidator id="lastnameValidator"
                source="{ lastnameInput }"
                enabled="{ lastnameValidatorEnableFlag }"
                required="true"
                minLength="2"
                property="text"
                triggerEvent="change"/>

        </validators:validators>

For more information on each of the libraries, whether you are after more comprehensive technical descriptions, or usage examples, you can visit the official web location.
Advertisements
This entry was posted in Adobe Technologies, General and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s