I was aware of Cairngorm long before I did any Flex work. But everything I've read says it's not worth the effort for smaller projects and I guess I consider our projects quite small. But when I started looking around the alternative frameworks they either seemed a bit immature or nearly as complex as Cairngorm (but without a strong support community). Consequently we've decided to bite the bullet and use this smaller project as a good place to start learning Cairngorm. To test the idea I built a really small module based project using Cairngorm. The first day was like pulling teeth, but each day after that it became easier and easier. I think the hardest thing about getting started with Cairngorm is there is no obvious starting point. There is an excellent series of six articles written long ago that provide a great insight into the thinking behind Cairngorm and some examples of how things are done. But it doesn't really explain all the elements and how they relate to each other. There are also a number of example applications over at Cairngormdocs that I highly recommend. But looking through these examples involved a lot of opening files and trying to make sense of how the different bits relate to each other. In the end it seemed there were quite a few balls to juggle and so I put together a small document defining our project structure with some notes on how the bits relate. Below are some outtakes from that document that might help fellow Cairngorm newbies. Now keep in mind I'm still a newbie myself so I'm probably off on a few points (I'd appreciate anyone who knows better correcting my mistakes so I'm not spreading mis-information). Each point looks at a typical folder you'll need for a Cairngorm project and their purpose :
- business : The business folder contains Services.mxml which defines all web service definitions (ie. HTTPService, remoteObject etc). Also add Delegate files here. Delgates initiate the service calls and listen and respond to results/faults.
- command : Create a Command for each action. Commands are called from the Views in response to user interaction. They could update the model directly or use a Delegate to make a service request.
- control : The Controller connects events to commands so that when the view dispatches an event through the CairngormEventDispatcher the relevant command is called. These connections are made using addCommand().
- event : define the custom events (that the control connects to a command) that will be called by the view to trigger commands.
- model : The Model stores all required state data. Bind views to the model properties so they reflect changes to the model. Update the model through commands or in response to Delegate results.
- view : The basis for all views in our project will be modules and hence in same folder as the main application file. But it still makes sense to encapsulate many view functions within their own components. These should be stored here.
- vo : Value Objects (vo's) represent more complex elements of the model. Store value object definitions here.