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.

While working on the Spring ActionScript framework, we wrote a lot of code that could perfectly be used outside of the framework. That's why we decided to start the AS3Commons project, based on idea of the Apache Commons project, and provide a set of core libraries useful to every ActionScript 3.0 developer.

This announcement is also the immediate release of 2 of the libraries included:

• AS3Commons-Reflect: a reflection library
• AS3Commons-Logging: an abstraction layer over logging frameworks

Note: we realize there is another as3commons library out there. However this library is no longer being maintained and developed as confirmed by the author. We apologize in advance for the confusion this might cause. We are currently looking into the code and will try to include/replace the functionality in the new project.

AS3Commons-Reflect

This is a reflection library, or a clear API written around describeType(). It allows you to get runtime information about classes and objects running in your application, like the properties and methods available in a class, the metadata associated with a certain property, ... and it also allows you to dynamically instantiate objects and invoke their methods.

We had previously moved this from the Spring ActionScript sources to the AS3Reflect project. However, since we had plans of extracting other part of the framework as well, we decided to bundle everything under the AS3Commons project. The AS3Reflect library is hence no longer available and we advice all users to update to the new release.

For more info, please see http://www.as3commons.org/as3-commons-reflect

AS3Commons-Logging

This is a logging abstraction layer over existing logging frameworks. It is a lightweight library that offers a logger interface and a set of adapters and decorators for existing logging frameworks, like the logging API in the Flex framework.

It is perfectly fit for library and framework developers that want to enable logging information in their distributed libraries without tying their code to a specific logging framework. Logging happens via the logger interfaces provided by AS3Commons-Logging and users are then able to configure the logger with the implementation they prefer.

Here's a small example:

We will update the project with new adapters for existing logging frameworks. Let us know if you have any framework that you would like to see supported.

For more info, please see: http://www.as3commons.org/as3-commons-logging

Get Involved

We welcome participation from all that are interested, at all skill levels. Coding, documentation and testing are all critical parts of the software development process. If you are interested in participating in any of these aspects, please join us! You can leave a comment or mail me at christophe.herreman [at] gmail [dot] com.

www.as3commons.org