December 8, 2008

Max Presentation - Flex Development with Cairngorm

At Max Milan last week, I gave a presentation on Flex Development with Cairngorm. The presentation was based largely on the "Cairngorm: Tips and Tricks from the Experts" presentation my colleagues Peter Martin and Eric Garza gave at Max in San Francisco, but after seeing the number of hands raised when Peter asked who was using Cairngorm, I thought I'd change the emphasis (and the content) a bit for the Milan audience.

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.

Posted by amcleod at 2:31 PM | Comments (4)

August 14, 2008

Cairngorm on Adobe Open Source - One Week On

So, Cairngorm has been on Adobe Open Source for over one week now, and I thought I'd summarize what's happened since.

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.

Posted by amcleod at 10:20 AM | Comments (1)

August 6, 2008

Cairngorm Moved to Adobe Open Source

Adobe Consulting is pleased to announce that the Cairngorm Micro-architecture has moved onto Adobe Open Source.

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.

Posted by amcleod at 12:50 PM | Comments (7)

November 14, 2007

Cairngorm - Commands and Responders

Recently, I've seen a few questions around Cairngorm and how commands and responders fit together when using asynchronous services with Flex. I'd like to clarify a couple of points.

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.

Posted by amcleod at 10:14 AM | Comments (7)

October 8, 2007

Cairngorm 2.2.1 Released

After a few months of being in beta, Cairngorm 2.2.1 for Flex has been released on Adobe Labs.

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.

Posted by amcleod at 5:23 PM | Comments (4)

May 30, 2007

New Release - Cairngorm 2.2.1 for Flex 2.0.1 with Hotfix 2

I posted last Friday about the release of Hotfix 2 for Flex 2.0.1, and how the moving of classes between the core Flex SDK and LiveCycle Data Services was causing a compiler error unless you had fds.swc on your library path.

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.

Posted by amcleod at 1:13 PM | Comments (8)

May 25, 2007

Flex 2.0.1 Hotfix 2 and Cairngorm

Flex 2.0.1 Hotfix 2 has been released today, containing a collection of Flex 2.0.1 bug fixes.

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.

Posted by amcleod at 5:06 PM | Comments (7)

May 17, 2007

Cairngorm 2.2 - Cairngorm Enterprise

In today's post about the recent release of Cairngorm 2.2, I'll give the reasoning behind the most obvious change made to the distrubution of the framework - the splitting of it into two parts, Cairngorm and Cairngorm Enterprise.

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.

Posted by amcleod at 2:40 PM | Comments (1)

May 3, 2007

Cairngorm 2.2 - Front Controller Weak References

In a continuation on my series of posts covering the recent Cairngorm 2.2 release, today I'll give the motivation behind another one of the changes that we made in the MVC micro-architecture for Flex: weak references in the front controller.

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.

Posted by amcleod at 11:16 AM | Comments (6)

May 1, 2007

Cairngorm 2.2 - Self Dispatching Events

Cairngorm 2.2, the latest version of the Flex micro-architecture, released on Friday, was a fairly minor release with just a few new features and minor fixes.

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.

Posted by amcleod at 12:09 PM | Comments (7)

April 30, 2007

Cairngorm 2.2 Released

The beta version of Cairngorm 2.2 for Flex has been kicking around for some time now, and, on Friday, I eventually got around to getting the release version up on Adobe Labs. You can read the release notes here.

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.

Posted by amcleod at 4:31 PM | Comments (13)

June 28, 2006

Cairngorm 2 - ASDoc Available

You may have seen by now that we have released Cairngorm 2 for Flex 2 over on Adobe Labs.

The Cairngorm 2 release on labs contains the source code only at the moment, but we're very busy in the background putting together more Cairngorm documentation and samples for the Flex community.

So, with a huge thanks to Brian Deitte of the Flex Team, we're able to provide you with the API documentation for Cairngorm 2. These docs can be downloaded from here for now, but we'll get the up on labs over the next few days.

The API docs are in the same ASDoc format as the Flex 2 Documentation, so should be immediately familiar to you.

I've already noticed a few formatting errors in the docs, and we will get those fixed for the release we put on labs, but please let us know if you think anything needs changed or updated in the meantime.

You can download the Cairngorm 2 documentation here.

Posted by amcleod at 8:20 AM | Comments (9)

May 9, 2006

Cairngorm 2 Stateless Commands

You may have seen over on Steven Webster's blog that Cairngorm 2 for Flex 2 Beta 3 has been released.

The main change in this release, compared with previous releases, is how commands are instantiated and used. I'd like to touch on the motivation behind this change.

In Cairngorm for Flex 1.x, a single instance of each command was instantiated by the controller and that one instance is used for each and every invocation of the command.

There are reasons why the original implementation was done in such a manner, mainly historical due to Cairngorm originally being developed for Flash applications, but since the advent of Flex, we've wanted to change it. With the API scrub taking place between Flex 1.5 and Flex 2, we see now is a good time to make this change.

Steven explains on his blog the single change you'll have to make to your concrete front controller because of this API change.

So now, rather than the single instance of the command being used for each command invocation, the front controller now instantiates a new instance of the command on each invocation. There are a couple of implications here:

1) If, in your existing Cairngorm applications, you rely on the same command being used for each command invocation, (eg, if you store state in the command, and reuse that state on the next invocation), you will have to change your implementation. What we'd recommend here is that you store your state in your model, possibly via the ModelLocator pattern.

2) Because a new instance of the command is instantiated on each command invocation, you can now store local state in that command for the duration of its invocation. This is particularly useful for cases where you make server side calls (eg, via RemoteObject). Previously, you'd have to use a pattern such as the Asynchronous Completion Token, but now, you can store your state in a command's instance variable in the execute() method (for example, you may store the event object), and then retrieve it again in your result or fault handler. We find this useful for cases where you want to update different parts of the model in the result handler, depending on the context of the initial command execution.

So, go get Cairngorm 2 for Flex 2 Beta 3 and let us know what you think.

Posted by amcleod at 4:14 PM | Comments (1)