I am trying to learn Cairngorm and am finding the resources severely lacking. I thought I'd document my experiences trying to learn Cairngorm with hopes someone will be able to tread the pass more easily than I.
Where do you go.
First off, where do you go to start reading about Cairngorm? Well, you can start at the Adobe Labs page on the framework. That will most likely lead you to Steven Webster's 6 part series on developing Cairngorm apps. Let's start with that series of articles.
Part 1 talks about frameworks in general, and gives a history of Cairngorm. It is a nice introduction and an easy read, but was unfortunately lacking any implementation details. It's not a complete waste of time if you're unfamiliar with frameworks.
The second article starts to get a little meatier. How do you maintain state in a Rich Internet Application built with Flex? In a web app, you are trying to force state on a stateless system by using URL variables or cookies. With Flex, you are not dealing with a stateless client. The flash player can deal with state.
Steven comes up with an interesting way to describe state in an RIA. The state is the model (of Model View Controller). When you're accessing a shopping cart, or user object you shouldn't be accessing them stored on a web server somewhere. You should access this data stored as part of the client.
The next part of the article talks about the Value Object. A Value Object is a design pattern, where the object represents a single entity. That entity may be a product, a person, a company, an address, or anything you need. Steven says that these objects are now called Data Transfer Objects. Conceptually, they sound exactly like what most CF Developers call a Bean. You can check out this Blog entry for more info on Value Objects, Coldfusion, and Flex.
With Cairngorm you can use Value Objects to help easily keep the state on your server in sync with the state on your client. I can understand that, although the article doesn't go into enough code detail for me to understand how to implement this.
The second part of the article ends off by explaining the model locator pattern. This is a brand new pattern designed strictly for Flex RIA apps. Steven explains that model locators don't apply to traditional web development or Java Development.
One powerful feature of Flex is data binding. When data changes, so does the display that uses the data. I got to admit it's pretty powerful. When developing Flex with lots of components and relationships between the components, you have a problem of how to find the component that needs the data. You could start at the top level application and work down to the data, like this:
That will get the productGrid values from the textualList component which is in the storeView component. It can get to be pretty tedious. I can honestly say I've never used this approach in a Flex app, and I'm not sorry about it.
An alternate method is that you could pass lots of parameters in and out of your component. In the example above, the productList value would be a property in textualList, which would then be a property in storeView. You do a lot of coding to specify the properties and components. It seems like a waste of time since many components will do nothing other define the property and pass it's value up or down. Unfortunately, this is a mistake I've made.
The model locator design pattern addresses the problem of how to access disparate data buried within different components that don't have an easy link between them. It is a single component that components use to access data. For all data and binding there is a single entry point across your application. This does address the two problems above.
The model locator component of Cairngorm is implemented as a Singleton. A Singleton is a design pattern, where only a single instance of the object is created for your application.
Summary So, after reading the first two parts of this article, I can tell you that Cairngorm uses Value Objects and a Model Locator. I like both of those ideas, although do not yet understand how I put this knowledge into practice when building a Flex application. I will continue to write more as I learn more.