Archive for May, 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:

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.

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.

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.

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.

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.