I wanted to answer a number of common questions surrounding Cairngorm:

* How do I get data from my Commands to my Model?
* How do I get data to my view?
* How can I be notified that new data has arrived on the view?
* How should Responders be implemented?
* How should I use the Model Locator?

So, the presentation is split into three main sections:

1) Cairngorm Overview

The first section is a back-to-basics introduction to Cairngorm, but with a twist. If you've been following some of the Adobe Consulting blogs recently, you'll have seen us talk about the Presentation Model pattern. Another of our consultants, Paul Williams, covered this in his well received series of Presentation Patterns and I show how the Presentation Model fits in with the standard Cairngorm Data Flow.

2) Cairngorm Best Practices

In the second section of the presentation, I provide some Adobe Consulting best practices for the use of Flex and Cairngorm, based on our many and varied engagements on mid to large scale enterprise applications.

The main topics covered are:

* Using the Presentation Model
* Using the Model Locator
* Events, Commands, Responders
* Updating Views with Data

During the talk, I went into detail on the Presentation Model in particular, and how it addresses many of the common questions we hear on handling data in Flex applications.

I also touched on unit testing with Cairngorm, Cairngorm and Modules, and Cairngorm and Data Management Services (part of LiveCycle Data Services).

3) Cairngorm Myths and Anti-Patterns

The presentation also gave me the opportunity to challenge a number of the misconceptions and misunderstandings I have seen on blog posts and architecture face-off discussions at conferences. I also spoke about some of the recurring mistakes we see people make when using Flex and Cairngorm. I covered the following:

* Do I Always Need to use a Framework?
* Do I Need to use every Cairngorm Pattern?
* Business Logic in Cairngorm Classes
* Use of the ModelLocator
* Use of Commands and Responders
* Use of the Controller

I hope to find time to provide more details on these best practices and myths in future blog posts.

At Max San Francisco, Peter Martin also announced the launch of the Cairngorm Plugin for FlexBuilder to allow the quick creation of FrontControllers, Events and Commands. The presentation ends with some details of that, and some road-map details.

My Max Milan presentation can be found on Adobe acrobat.com, here. You can download it via the Download link near the top-right of that page.

Following on from the news that Cairngorm has been moved to Adobe Open Source, it is my pleasure to announce that FlexUnit, the unit testing framework for Flex applications, now has a new home on Adobe Open Source.

FlexUnit started its life almost 5 years ago, when I first wrote AS2Unit; at that time, it home was the iteration::two website. FlexUnit was borne from that project, and was released shortly after Flex 1.0 in March 2004.

With the release of Flex 2, a team from Adobe Developer Relations migrated the framework to ActionScript 3 and gave it a new home on Adobe Labs. However, it was soon on its move again, and ended up on Google Code as a 0.85 release of as3flexunit.

Since that time, a number of bugs have been identified, and a number fixed, but there has been no real visibility of ownership; no-one has the responsibility to build and test and release new versions to the community and the 0.85 version is fast approaching 2 years old.

We see this move as bringing FlexUnit back to its Adobe home, where it can get the attention and care it deserves.

Adobe Open Source brings a number of benefits:

* Source available via a Source Control System (Subversion)
* Availability of a bugbase for bugs and enhancement requests (JIRA)
* Developer forums for the discussion of features and roadmap
* Ability to submit code patches

Alongside this move, we've also taken the opportunity to do some bug fixes and have also add some new features to FlexUnit. The codebase for this release is based on revision 20 from Google Code. We realize that there have been a few subsequent changes made to that codebase since we had to branch to make our own bug fixes and enhancements, and we look to the community to reintegrate any of these changes, as necessary. We have chosen to go down this route rather than delay the release further.

The most visible set of changes to FlexUnit, and something you've probably already noticed from the screenshot above, is in the graphical test runner, designed by the User Experience team at Adobe Consulting.

Within the runner, we've added more information about the tests being run. We've provided the average number of asserts per test case, and also the number of asserts in each individual test case.

When tests do fail, we've extracted the failure information to make it clearer to the user, and, so long as you have compiled your tests with debug set to true, and are running with the debug flash player, you will also see the stack trace, to give that extra level of information not necessarily previously available.

Finally, you can now also filter your test results, for those larger projects where you have hundreds of test cases.

You can filter on individual test case names, test names, expected results or actual results, and also choose to see results based on all test cases, only those with errors or failures, or just empty test cases.

We are incredibly excited about this move, and look forward to the community getting involved through the submission of enhancement requests, code patches, documentation and taking part in the discussions around FlexUnit.

I was hoping to contact the project members of the existing as3flexunit project; unfortunately, Google Code does not let me easily identify the current members. So, if you wish to contribute to the project, please contact me.

The FlexUnit home page on Adobe Open Source can be found here.

It has been interesting to watch the community response to my announcement. To Adobe Consulting, this was a move of an already open source project from Adobe Labs to Adobe Open Source, but while the response has been extremely positive, many of the reports read as if Cairngorm becoming open source was something new.

I guess this says something about our previous messaging, and the fact that the setup on Adobe Labs wasn't the same as Adobe Open Source, where we now a full source code hosted on Subversion and available to all, rather than a single ZIP download of the source.

As i explained in my announcement, we made a conscious decision not to add any new features in the process of the move. We did, however, provide the facility for community feedback, and already, we've had a good amount of involvement.

Over on the Cairngorm Forums, we've had various discussions, including those on creating a test suite for Cairngorm, tooling support for Cairngorm within Flex Builder and how we should approach extending Cairngorm.

The Cairngorm Bugbase has sprung into life too, and Christophe Herreman has already submitted patches containing some initial unit tests, alongside two other bug reports with patches. We've also had an enhancement request, for better support for Cairngorm with Flex Modules.

JIRA, on which the Cairngorm bugbase runs, has a voting facility, so please get invovled, and vote on the bugs and enhancement requests you think should be part of a future release.

What next?

A team from Adobe Consulting met on Monday of this week to discuss the Cairngorm roadmap, both in the short-term, to apply the patches provided and ensure Cairngorm is fully up to date with the latest releases of the Flex SDK, BlazeDS and LiveCycle Data Services, and also looking to the future, and Cairngorm 3.

We'll be socializing our thinking over the coming weeks

In the meantime, we encourage you to get involved in the discussions taking place on the forums or to submit enhancement requests to the bugbase.

Its hard to believe that Cairngorm is approaching 4 years old - Steven and I announced it at the Max conference in New Orleans in October 2004 and the first version was released soon thereafter.

We've gone through a number of different versions since then, but each one has always held true our vision: Provide a lightweight MVC architectural framework around which to build Rich Internet Applications with Adobe Flex or Adobe AIR.

The latest version, Cairngorm 2.2.1, was released back in October 2007 and, although we at Adobe Consulting consider that being a good reflection as to the maturity of the framework, there have been some questions on when the next release would be made available and what new features it would have, alongside some specific feature requests.

At Adobe Consulting, we've always had a minimalist approach to Cairngorm; we don't want to add feature for feature sake, add functionality that doesn't belong within an architectural framework, or introduce another design pattern into the mix because it's the latest fad in the software industry. The framework is there to allow us to build well-architected software solutions, and we've only ever added features we truly believe helps us do that.

There are no new features in this release - at this time we are simply moving Cairngorm 2.2.1 from Adobe Labs to Adobe Open Source.

However, we do listen to the community and to our customers, and this announcement is in response to this invaluable feedback. We hope that this launch will emphasize the commitment that Adobe has to the framework, and reinforce the message that the framework is the one that Adobe Consulting visibly advocates.

There are many benefits to having Cairngorm on Adobe Open Source. Alongside having a well defined home for downloading the framework, its documentation and samples, Adobe Open Source also provides additional resources one would expect of an open source project:

* Source available via a Source Control System (Subversion)
* Availability of a bugbase for bugs and enhancement requests (JIRA)
* Developer forums for the discussion of features and roadmap
* Ability to submit code patches

Alongside this move, we are also introducing a level of governance, a charter that explains how the Cairngorm project will be managed, and how leaders in the Flex community can get involved in the project.

We are also extending an open invitation to the community to submit bugs or feature requests and take part in the Cairngorm discussion forums.

The community has read-only access to the Cairngorm source code by default, and contributors will also be able to submit code patches.

We are incredibly excited about this move, and look forward to the community getting involved in the framework, through the submission of enhancement requests, sample applications, code patches, documentation and taking part in the discussions on the future direction of Cairngorm.

The Cairngorm home page on Adobe Open Source can be found here.

A Command need only implement the Flex IResponder interface if it is to be the responder for an asynchronous service call.

This is probably obvious to many, but I've seen Command classes which implement IResponder, but don't do any ansychrnous service calls and have empty result() and fault() methods. In this cases, the Command should implement the ICommand interface only and not the IResponder interface.

The Command class does not have to be the responder for asychronous service calls.

I've not seen many implementations like this, but the Cairngorm command pattern is designed in such a way that your responder can be an instance of another class, as in this example:

public class AddTaskCommand implements Command
{   
  public function execute( event : CairngormEvent ):void 
  {
    var addTaskEvent : AddTaskEvent = event as AddTasksEvent;
    var task : Task = addTaskEvent.task;

    var addTaskResponder : AddTaskResponder = new AddTaskResponder( task );
    var delegate : TaskDelegate = new TaskDelegate( addTaskResponder );
         
    delegate.addTask( task );                  
  }
}

public class AddTaskResponder implements IResponder
{
  private var task : Task;
   
  public function AddTaskResponder( task : Task )
  {
    this.task = task;
  }

  public function result( event : Object ):void 
  {
    //handle the result here
  }

  public function fault( event : Object ):void 
  {
    //handle the fault here
  }
}

This implementation allows better separation of logic and potential reuse of responders, and also makes things easier to test.

There is nothing new in this release over previous releases; it's only purpose is to align Cairngorm with the moving of SWC libraries in Flex 2.0.1 with Hotfix 2 and LiveCycle Data Services 2.5.x.

The fix at that time was to include fds.swc on your library path, even if you did not use or need LiveCycle Data Services 2.5.

I've now created a new build of Cairngorm and Cairngorm Enterprise that is aligned with the new packaging of Flex 2.0.1 with Hotfix 2 applied and with LiveCycle Data Services 2.5. This packaging should also work for standard Flex 2.0.1 installations.

I've had to put this package together quite quickly and full testing hasn't taken place, so this release is a Beta for now.

The only change in this release is the moving of the Consumer and Producer service locator methods from the base Cairngorm ServiceLocator into the Cairngorm Enterprise EnterpriseServiceLocator class.

You can download the packages here:

• Cairngorm 2.2.1 Beta Binary (SWC)
• Cairngorm 2.2.1 Beta Source
• Cairngorm 2.2.1 Beta Documentation
• Cairngorm Enterprise 2.2.1 Beta Binary (SWC)
• Cairngorm Enterprise 2.2.1 Beta Source
• Cairngorm Enterprise 2.2.1 Beta Documentation

I've leave these package on this blog for now, until feedback has been received, and then I'll get them moved over onto the Cairngorm page on Adobe Labs.

As part of this release, some classes, which are not required as part of the core SDK, have been moved into Flex Data Services (FDS), now rebranded LiveCycle Data Services 2.5 (LCDS 2.5) and newly released.

However, because the ServiceLocator class of Cairngorm has a soft reference onto the Flex framework's Consumer class, applying Hotfix 2 will cause the following compiler error in your Cairngorm application, unless you have fds.swc on your classpath.

1046: Type was not found or was not a compile-time constant: Consumer.

We will be releasing another version of Cairngorm and Cairngorm Enterprise, which will align themselves with the new class locations in Hotfix 2, and also be compatible with the standard Flex 2.0.1 release. In the meantime, if you update to Hotfix 2 or switch to LiveCycle Data Services 2.5, ensure you have fds.swc on your classpath. You can get this from the new LiveCycle Data Services 2.5 release.

The main reason for the change at this time was to remove Cairngorm's dependancy, introduced in Cairngorm 2.1, on the Flex Data Management Services library, fds.swc. This dependency forced developers to download Flex Data Services, even if they were using Cairngorm with a relatively simple applications that used RemoteObject, HTTPService or WebService only.

Mea culpa, as they once said.

However, this change also hints at the longer term roadmap view of where Cairngorm is heading.

Our vision is that Cairngorm will have a core framework, which mid-sized applications will use. Alongside that, we foresee the need for a set of additional modules, for use in enterprise-scale applications.

These modules will contain repeatable, best-practice solutions to common application problems and will address areas such as:

• Extended support for Flex Data Management Services
• Extended support for Flex Messaging Services
• Platform specific module for Apollo
• Product specific module for LiveCycle Enterprise Suite
• Security and authentication modules
• Others we haven't thought about yet

The modules could vary in architecture, from a simple set of command, delegate and service definitions, or even some server side Java code (eg, for LiveCycle ES), through to new sets of classes that implement the common patterns we see emerging in our solutions.

We expect the modules to surface as best practices out of our day-to-day consulting work, rather than by us attempting to determine the solutions upfront. As such, we cannot commit to any specific date for any new features, but we can say that they will remain free and open-source.

As always, we welcome your feedback on our thoughts.

In Cairngorm 2.1, the base FrontController class added itself as a listener onto the CairngormEventDispatcher as follows:

CairngormEventDispatcher.getInstance().addEventListener( commandName, executeCommand );

meaning that, when Cairngorm events are dispatched at various places throughout the Flex application, the controller would be notified, and the executeCommand() method called. However, the line of code above added the controller to the CairngormEventDispatcher as a hard reference, meaning that the controller would never be eligible for garbage collection while the CairngormEventDispatcher was still in memory.

Fast forward to the release of Flex 2.0.1 and the addition of Module support to the Flex framework. This feature gives us the ability to load and unload parts of our application, dynamically, at runtime. With Cairngorm 2.1, if someone wanted to create a Cairngorm application as a module, even if that module is unloaded, the controller would never be eligible for garbage collection because the CairngormEventDispatcher (which is a singleton, and therefore global) still has a hard reference onto it.

So, in Cairngorm 2.2, we have made, by default, the addition of the controller to the CairngormEventDispatcher as a weak reference. Holding objects as weak references means that the object will be eligible for garbage collection if the only references to it are weak.

Now, when the FrontController is unloaded, and assuming that all other hard references to it have also been removed, the controller will be eligible for garbage collection, because the CairngormEventDispatcher only has a weak reference onto it.

You can still decided to add the controller as a hard reference to the CairngormEventDispatcher, via a parameter of the addCommand() method of FrontController, but I see little need for that.

There is one final point to add here. The ASDoc for the addCommand() method of FrontController states that the command is added as a weak reference to the controller. That is just plain wrong and I hold my hand up to that - the comments were added in a rush just before I did the final build, instead of when I did the code change. The docs will be fixed in the next release.

However, I thought it would be worthwhile for me to document the motivation behind some of the changes.

Today, I'll give a quick overview of self-dispatching events, which were added to the 2.2 release.

With Cairngorm versions up to and including 2.1, to dispatch an event that would be handled by your controller, you had to do the something like this:

var loginEvent : LoginEvent = new LoginEvent( username, password );
CairngormEventDispatcher.getInstance().dispatchEvent( loginEvent );

If you had many events in your application, this became a pretty long-winded way of doing something as simple as dispatching an event.

With Cairngorm 2.2, we've added a helper method to CairngormEvent, which all your controller events should extend. Now, you can do the following:

var loginEvent : LoginEvent = new LoginEvent( username, password );
loginEvent.dispatch();

Or even:

new LoginEvent( username, password ).dispatch();

Its a matter of personal style on which of these two you prefer, but they both give much more clarity to your code and (more importantly for some) need less typing.

The main change in this release is the externalisation of dependencies on the Flex Data Services library (fds.swc) to a separate set of downloads called Cairngorm Enterprise.

The full list of changes in this release are as follows:

• Removed dependency on Flex Data Services (fds.swc) - externalised to Cairngorm Enterprise
• Flex SDK SWCs are no longer linked into Cairngorm.swc (produces a smaller Cairngorm.swc)
• Added support for setting remote credentials
• Fixed bug with Web services not loading the WSDL (no need to call loadWSDL() explicitly)
• ModelLocator interface has been deprecated. Added com.adobe.cairngorm.model.IModelLocator
• Added deprecation metadata for compiler support
• Added dispatch() helper method to CairngormEvent class
• Commands are now added to base Controller with weak references
• Added removeCommand to FrontController
• Made commands instance variable protected in FrontController (was private)

If you want a more general overview on what Cairngorm is, and what it can do for you, visit the Cairngorm page on Adobe Labs.

I'll give the motivation behind many of these changes in future blog posts.