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.

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?

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:

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

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!

We want to be able to execute commands in a sequence, where each command needs to be executed after the previous command has finished. This can be right after a call to execute() in case the command only implements ICommand, or after the invocation of the result() or fault() method, in case the command implements the IResponder interface and fetches some remote data.

The way to do this in Cairngorm is to let your command extend SequenceCommand - which acts as an abstract base class for commands that are executed in a sequence. Then you assign a value to the nextEvent property and call the executeNextCommand() method. This is done in the execute() method, the result() or fault() handler of the command. Each sequence command contains logic that says which command to execute next.

This has a major drawback though: since the sequence logic is coded in the commands themselves, it is very hard - not to say impossible without extra conditional logic - to reuse the command outside a sequence or in another sequence.

Solution

Instead of extending SequenceCommand and coding the sequence logic in the commands themselves, let's define a sequence of events outside of the commands. The commands themselves should not extend SequenceCommand. This will allow us to create "standalone" commands that have their specific task and then chain them into a variety of sequences.

Explanation

The solution Prana offers comes in the form of the EventSequence class. As said earlier, we want to have a non-intrusive way of defining sequences of events/commands without the need to code sequence logic in the commands. As an example, let's take an event that causes the user to log in, after which another event is dispatched to fetch the latest private messages for that user.

In Cairngorm we would have the following:

In the above code, the sequence logic in the result() handler prevents us from reusing the command outside of the sequence or in another sequence. This will most often result in duplicate code which makes the code base hard to maintain.

Looking at the flow of events and commands, we see that in most cases (but not all) a command will update some property in the ModelLocator. This is a good practice, because it keeps your commands consistent across your application: a command executes, proxies a remote call through a business delegate, adds itself as a responder to the remote call, updates the ModelLocator in the result() or fault() handler.

Example

Let's dive into an example of the EventSequence. I'll explain the different parts individually:

Explanation

First thing we need to do of course is create a sequence. We can do this by creating an instance of EventSequence.

Next, the sequence expects us to define different events in it so that it knows when to fire which event. We do this by calling addSequenceEvent() on the sequence and passing in the properties of the event we want the sequence to dispatch.

The first argument is the class of the event. In our case this is LoginUserEvent with has 2 constructor parameters: username and password. These parameters are defined in the second argument of the addSequenceEvent() method as an array.

There are 2 options:
1. we pass in concrete values
2. we pass in an instance of Property which let's us define a lookup of a property (if you are familiar with BindingUtils, you will already know how this works)

The first option, passing in a concrete value, is quite straight forward. In case of the LoginUserEvent we pass in the credentials of the user, which will normally be fetched from the text inputs of the login form. So the definition of this could look as follows:

The second option is a property that will be evaluated or looked up at runtime and is defined by a host and a chain. In case of the second event, we want to pass in the user's id, but we can only do this if the user is defined in the ModelLocator and has a valid id (this will be after executing the LoginUserCommand). Doing the following wouldn't work (don't worry about the 3rd argument for now):

This will result in a runtime error (null pointer exception) because we want to pass in the concrete value of the user's id when we define the sequence. Since the ModelLocator does not contain a valid user instance at that point, this won't work. Therefor we need to define the value as a property of which the value will be "looked up" when we really need it (that is when firing the next event in our case).

The property defines a host: that is the variable that contains - or better will contain - the needed parameters for the event. In our case this is the model locator, so ModelLocator.getInstance(). The remaining arguments of the property instance are a chain of properties of the host defined as strings. So to get the user's id from the model locator we would define the following:

The 3rd argument of the addSequenceEvent() defines a trigger that will instruct the next event to be fired. In the example above, the next event will get fired when the user property of the model locator has changed.

After we have defined the sequence, all we need to do is call it's dispatch method. Also, the event/command mapping is still defined in the front controller, just like you would do without sequences. We do not need to specify any custom mapping.

Where to create sequences?

Normally I create a subclass of EventSequence and define the sequence in the constructor. I then instantiate the sequence in the appropriate view and dispatch it from there.

An alternative approach could be that the front controller has support for defining sequences. We would then have a centralized place for specifying these sequences instead of having them scattered in different classes. In this case there should also be a way of launching a sequence from the view. I don't have an answer for that right now, but I'll put some thinking into that.

What if the command does not update the model locator.

There will be times when a command does not update a property in the model locator. So we don't really have a point in time when we know we should trigger the next event. To solve this, the CairngormFrontController registers every executing command in a central registry called the PendingCommandRegistry. The command then has do decide when its action is finished and unregister itself:

When calling unregister, the event sequence will get notified of this and trigger the next event if any. Note: this is not yet fully implemented in SVN and is more of a theory at the moment.

Conclusion

I personally think that this is a good approach to chaining events/commands. Especially because of the non-intrusive way this problem is handled. If you have any ideas or comments, feel free to leave them here or join the Prana list or Cairngorm list so we can discuss this.

Hope you enjoyed this and keep on coding!

Update 2007/10/12: added explanation of the triggers argument of addSequenceEvent()

while it really should be:

This is just a mistake when typing fast and with code completion but it can take a while until you find out what you did wrong. To prevent this, I decided to override addCommand() in Prana's CairngormFrontController and add in a check to see if the commandRef argument actually is an implementation of ICommand.

You can checkout this code from Prana's SVN if you like, or you can build a custom version of Cairngorm with the following code:

This should save you some time in the future.

On a side note, I have been working on an alternative approach to chaining events/commands in Cairngorm. The code is already in Prana's SVN but I haven't had the time to blog about this. Check it out if you're interested and mail me if you want a code example. In the meantime, I'll work a blogpost with an example on how to use it and will publish this by the end of the week.

Happy coding!