Christophe Herreman

Cairngorm 3 was recently announced by Tom Sugden and Alex Uhlmann and has now been released in beta on the Adobe Opensource site.

Don’t expect an updated version of the Cairngorm framework as you know it though. Cairngorm 3 is not aiming to be an MVC implementation, and thus moves away from what version 1 and 2 were, but now consists of a set of patterns and practices, together with a series of libraries that can help to solve common problems.

The Patterns & Practices Group at Microsoft have been promoting a similar mindset for quite some time actually: Prism – patterns & practices Composite Application Guidance for WPF

I can only encourage this decision as it is exactly how I personally think about application design and architecture, especially in Flex and AIR applications. This is also what we are trying to do with Spring ActionScript: our main goal is to provide a solid Inversion of Control container that supports multiple configuration options (XML, MXML, metadata driven component scanning, …) and promote it as a foundation to build applications (and frameworks), with or without your favorite MVC framework. Although we are working on a set of base classes that provide infrastructure for your application (under the name MVCS) with Application Events, Controllers, Abstractions for service layers, … by no means do we want to market the Spring ActionScript framework as yet another MVC implementation. (You might wonder why we are calling it MVCS then, and I’m actually wondering the same… I guess marketing and buzzwords in the opensource world are also important. All kidding aside, the name is certainly subject to change).

What’s in a name

Since this is a complete change of direction for the Cairngorm framework (which it actually no longer is) I would have expected a new name. Continuing to use Cairngorm as a name is in my opinion a bad move and will cause major confusion amongst developers and other people involved in the development process. I think the best thing for Adobe, or at least their Technical Services department, would be to let go of the name and choose a new, fresh name that moves away from the past. (Besides that, who can pronounce “Cairngorm”.)

Dependencies

I noticed that some of the modules that Cairngorm 3 provides depend on other libraries/frameworks, and in general the Parsley application framework. While Parsley is certainly a major player amongst the IoC/application frameworks, and I sincerely respect the author’s work, I don’t think this is a good decision. In case you are wondering: Yes, I would say the same thing if they decided to depend on Spring ActionScript.

The usage and choice of a concrete dependency will have consequences for the adoption and integration of the libraries that Cairngorm 3 provides. Think about it: Why would you want to pull in Parsley, perhaps only to use some of its Reflection API, if you are already running on Spring ActionScript or any other IoC container?

We, the Spring ActionScript team, have actually questioned ourselves about this in the past and have therefore decided to move all the common and reusable code from Spring ActionScript into a set of libraries known as the AS3Commons project. In that respect, I’m a bit disappointed that for instance the AS3Commons Reflect library is not used for reflection purposes, since I think it is more abstracted and unintrusive than a subset of an all-encompassing application framework. Perhaps this may be our fault of not promoting the libraries and the project enough. However, I certainly think that AS3Commons could be a wonderful project and would help to provide common libraries not only to Flex and AIR developers, but to ActionScript 3 developers in general, if it were embraced by the community.

Flex and MVC

Given that RIA technolgies are still evolving at a very fast pace, it is really remarkable to see the huge amount of MVC implementations appear. Not specifically aimed at Cairngorm (at least the previous versions), but rather at almost all MVC architectures available for Flex development, my personal feeling and experience is that the use of MVC architectures in the Adobe RIA space is almost a dogmatic thing and is not needed in most cases. The problem is that people just take an MVC framework as it is and implement it in their applications. More than often not questioning whether or not its usage is justified. Things that could easily and cleverly be solved are ripped apart across layers of the architecture, introducing levels of indirection that are in most cases not needed. The only thing they add is complexity and counter-intuitive development practices.

One of the main arguments for using an MVC framework is that the code is “easy to understand”. Of course the code will be easy to understand if you have been developing with the framework of choice for the N-th time or if you have been digging into the code for a serious amount of time, but ask a newcomer to look at the code and try to explain to you what it is actually doing… I think you’ll be surprised by the responses.

I’m not saying that the use of a particular MVC framework is de facto a bad thing, but the “religious” use and the blind adoption and implementation make a framework a killer for your application. I would encourage everyone to start their next project without an MVC framework and just use the Flex framework with a healthy knowledge of design and presentation patterns. And even if you are using an MVC implementation, think about each layer you introduce, why you need it and the pros and cons it brings.

Conclusion

It’s good to see that Adobe is rethinking their approach to RIA architecture and development practices. I also hope that they will be more open to community input and feedback than they were in the past. Although they did several attempts at engaging the community, I don’t think they really succeeded in that. If not open enough, people will just continue to fork the “framework” and provide extensions that will end up in alternative implementations anyway.

I’m looking forward to seeing how all of this evolves.

In the last months there have been several blog posts about the evil that is Cairngorm. People are complaining about the framework on mailing lists and on forums and when talking to other developers, a lot of them seem to dislike Cairngorm, mostly in favor of other frameworks. Some projects I consulted on (often too late) were actually being refactored/rewritten to move away from Cairngorm.

I noticed however that the opinions often lacked strong arguments, if any at all, that were convincable enough for me to truly dig into other frameworks. In some cases, I felt that the choice of a framework was based on a hype and prejudgement towards other frameworks. In particular PureMVC is getting a lot of attention and I can’t remember how many developers I have heard saying that they were using PureMVC just because “Cairngorm sucks”.

Don’t get me wrong. I certainly don’t want to start a religious war between the Cairngorm, PureMVC and other framework followers. I’m all for a little “competition” because I believe it drives innovation. We’re even offering extensions to both frameworks in Prana and since people are using them, there certainly will be good reasons that justify the use of one of the two frameworks.

However, I was wondering what your opinion was on Cairngorm. What in particular is it that you don’t like about Cairngorm and if you could change things, what would they be? On the other hand, what things do you absolutely like about the framework?

Following up on Douglas McCarroll's modified Cairngorm Store update, I thought I'd take this a step further and add a Prana application context to configure the business delegates and the service locator. This example has support for mock delegates that contain hardcoded local data and is also able to connect to php services using Remote Objects and AMFPHP.

This examples replaces the older Cairngorm Store example that was configured to work with AMF0 and Renaun Erickson's RemoteObjectAMF0. It now uses the latest beta version of AMFPHP and the AMF3 protocol. The services are hosted on this domain so you don't need to setup AMFPHP in order to see this in action.

The code is currently in svn and can be checked out at http://prana.svn.sourceforge.net/viewvc/prana/trunk/samples/PranaCairngormStore/. This sample will also be included in the next release.

Here's a snippet from the readme file:

***

The following files have been added/changed in order to add Prana configuration support for business delegates and service locator:

* Main.mxml: added application context loader and forced compilation of configured classes

package com.adobe.cairngorm.samples.store.business
* BaseBusinessDelegateMock.as: implements IResponderAware, removed responder constructor argument
* CreditCardDelegate.as: extends AbstractRemoteObjectDelegaten, implements ICreditCardDelegate
* CreditCardDelegateMock.as: implements ICreditCardDelegate
* ICreditCardDelegate.as: interface for credit card delegates
* IProductDelegate.as: interface for product delegates
* ProductDelegate.as: extends AbstractRemoteObjectDelegaten, implements IProductDelegate
* ProductDelegateMock.as: implements IProductDelegate

package com.adobe.cairngorm.samples.store.commands
* GetProductsCommand.as: added delegate lookup via ShopModelLocator
* ValidateCreditCardCommand.as: added delegate lookup via ShopModelLocator

package com.adobe.cairngorm.samples.store.model
* ShopModelLocator.as: added creditCardDelegate and productDelegate variables to configure business delegates

***

As a result, we can now lookup the implementation of our business delegates in the commands instead of instantiating new ones. The commands are completely unaware of the implementation of the business delegates. One note though: since we are not creating new delegate instances, we need to set the responder as a property of the delegate before calling its methods.

Here's how the application is configured in the application context to use the mock delegates:

And here's how the remote object delegates and the service locator are configured:

I'm proud to announce that Prana 0.3 has been released.

Some of the key features and updates:

• major update to the core IoC container
• support for templates in the application context (blog post)
• support for initializing objects in the application context (Log example)
• compliancy with Spring application contexts
• event sequencing in Cairngorm (blog post)
• several utilities

In the coming days, I'll post some more about the new features.

General info: http://www.pranaframework.org
Download: SourceForge Download Page

Changes in version 0.3 (24.11.2007)
-----------------------------------

General
* added Movie sample application based on article by Martin Fowler
* improved documentation
* moved Cairngorm related classes to org.pranaframework.cairngorm
* Cairngorm Store sample now has different configuration of service locator

Package org.pranaframework.cairngorm
* added support for event sequencing
* CairngormFrontController now checks for commands implementing the ICommands interface
* implementation of CairngormServiceLocator

Package org.pranaframework.errors
* added ClassNotFoundError for retrieving a class by name when class was not found

Package org.pranaframework.ioc
* added serializer to create an application context from an object
* added support for initializing object with IInitializingObject
* added support for templates in application context
* added support for <map> definitions, parsed to Dictionary
* added support for <list> definitions, parsed to ArrayList
* made container spring context compliant
* improved error handling when creating object from object definitions
* rewrote preprocessing of xml application context, now using chain of preprocessors
* fixed creation of object without id, id is now auto generated
* fixed order for object definitions so that they no longer need to be chronological

Package org.pranaframework.reflection
* added metadata introspection
* added "getFullName" method to Method class
* changed arguments in "invoke" method from ... to array

Package org.pranaframework.utils
* added "forName" method in ClassUtils for retrieving Class objects via class names
* added "getParentClass" method in ClassUtils that returns the parent class of a given class
* added "isSubclassOf" method in ClassUtils that returns if a class extends another class
* added StringUtils
* added DisplayObjectContainerUtils
* added MethodInvoker to support initializing objects from application context
* added "state" method to Assert class
* changed TypeConverter so that it can return Class objects

In case you haven't read this, Tony Hillerson has posted an article on configuring a Business Delegate Factory for Cairngorm with Prana. This allows you to quickly switch between different implementations for testing or production purposes.

Read it at http://thillerson.blogspot.com/2007/10/delegate-factories-with-prana.html

It's good to see that the community is picking up Prana and benefits from it. Keep on supporting the project guys, thx!