Easy coding to understanding Cairngorm

2 09 2008

Update: The below post is a how-to for the legacy Cairngorm 2 framework. Cairngorm 2 relies on static singletons and as such cannot be properly unit tested. It is a legacy framework and should no longer be used for RIAs.

Please look at Adobe’s prescription for Cairngorm 3. Consider using a modern micro-architecture such as Robotlegs or Parsley.

Ok, so I’m not going to try and teach the Cairngorm micro-architecture for Flex here.  The kids at Adobe did a fine job of that.

What I am showing here is, a very simple implementation of Cairngorm. Even though I’d seriously recommend anyone starting out to look at the Cairngorm Store first, I thought I’d share my experience implementing a tiny  Cairngorm solution. The solution here is essentially paraphrasing the Cairngorm Store source.

You can download the project here.

Note: it is set to run from http://localhost/TestCairngorm (you’ll need to setup this Virtual Directory to test it locally)

The project’s goal is to show the contents of an XML file, which will be deployed alongside the application.

It illustrates the steps needed to get your project off the ground in Cairngorm:

  1. Write a bindable model that extends from ModelLocator. Remember: the Model shouldn’t know anything about either the View or the Controller.
  2. Include code to the Singleton of that model in your main application
  3. Create your value objects (this was not strictly required in the above project, but added to highlight the correct structure).
  4. Write a services file that extends the ServiceLocator and contains all the services you want to access (HTTP/Web/Remote).
  5. Add the services to your main application.
  6. Write a delegate for each type of value object you have. This is optional but seems best-practise.  The delegate will call the appropriate service via the service locator for each method it provides. It will ensure the responder (the command that calls the delegate) receives the response.
  7. Write a command for each of the various commands you have within your application. These should execute() the call to load your remote data via the delegate and handle the reception of data in result() (and likely modify your model)
  8. Write an event that corresponds to each command along with any data that will need to accompany the event (user data or what-have-you). Doesn’t have to be one event per command – you can combine events together in one class with different types.
  9. Write a controller (extending from FrontController) that adds all the commands to this Singleton when instanced (tying the events and the commands together)
  10. Add the controller to the main application.
  11. Start creating your view. Ensure that you bind your view items to your model elements, so that when the model updates, so will your view. Try not to reference your model in your view via the Singleton class name but rather pass the appropriate model data in from the main application. (This helps improve the reusability of your view, decoupling it from the model).
  12. Use the CairngormEventDispatcher to dispatch your events in the view as you see fit. This will then call the commands via the controller, which call the appropriate service, update the model if required, and will update your view.