Archive for the ‘Cairngorm’ Category

Cairngorm 101: Take one

March 28, 2009

Here is how things are set up in Cairngorm v2.2, based on what I learned this morning through this series of step-by-step tutorials (text accompanied by videos):

  • The members in views are bound to the model locator using Flex binding. This is the foundation of the whole mechanism, which ensures whenever the model is changed, the corresponding views get updated. Flex uses [Bindable] meta data tags for binding properties and setters.
    Note that there are situations where bindings cannot be used or you prefer not to use bindings. For example, properties of the main application is not binable, which means you cannot bind width/height property of your WindowedApplication to some properties of your model locator. All the code inside a [Bindable] setter is lazy execution (meaning if you are trying to assigned the same value using the setter, nothing will happen).
  • You will also need to declare and instantiate the Control in your Main application, either by ActionScript or by MXML, in order for the whole thing to be set in motion.
  • The following shows how different parts are chained up in the Cairngorm flow to react to a user gesture. Note this flow doesn’t include a detailed view about how Model delegates to the business logic (residing largely on servers):
    View->Event->Front Control->Command->Model->View
    (here is a much nicer looking diagram from the original site)
  • ModelLocator is a singleton class that contains all the model/data classes plus the states of the models (such as “login”, “checkout”, “view in thumbnail”, “view in grid”, etc..) Again, in Cairngorm, the model updates views by utilizing the Flex binding mechanism.
  • Model classes (TODO)
  • Business delegate classes (TODO)
  • Command is the worker class who does the heavy lifting. Usually, it knows the business logic and carries the underlying algorithms. In your code, there should be defined separation of labor among Command objects and each Command should only concentrate on one thing. Each command object is associated with a a typed Cairngorm Event, which is passed down from the Front Controller. All Command objects carry out their duties by responding to a centralized Front Controller instead of directly to a user request.
  • Then how does a user request get satisfied? In Cairngorm, all the hooks between user gestures and their corresponding workers are done by the Front Controller. Front Controller is the manager class that keeps the list of commands for your application and keeps track of which command responds to which user guestures (presented as CairngormEvent objects). At the time an event is dispatched, it invokes the excute() method on that command and passes the typed Cairngorm event object which contains information about the specific user gesture that the Command object expects. The philosophy for Command/Cairngorm Event/Front Controller is similar to that of  Mediator Pattern: Encapsulating all the worker objects’ communication by decoupling the explicit dependency of objects on one another.:)

Here is how I approach the code flow, which for now I feel easier to follow:

  1. Create ModelLocator. This includes adding related model/data and “states”. This is like blocking of your drawing. After this, we can drill down into the details:
  2. Create VO;
  3. Layout View (UI control);
  4. Define event for the control;
  5. Create command to handle event. The command is the control in the MVC pattern, it interprets an user gesture and modifies the model ;
  6. Add the command to the Front Controller. This is like in your drawing when you are happy with the details, you step back again to adjust the relations of different parts ;
  7. Add Front Controller to the Main application if you haven’t done so,
    Add view/UI controls to the Main application if you haven’t done so;
  8. Go back to #3 > #6 to add more features.