Thanks for your input. The future of Cairngorm seems to look interesting from what you’d written. I am looking forward to it’s official release.

Please allow me to correct a few points re. Parsley and Cairngorm. You wrote that apparently Cairngorm will be pretty much like Parsley, but the truth is more subtle. Some of the Cairngorm beta libraries are implemented as Parsley extensions, because Parsley provides extensibility points that make it easy to create higher-level framework features. Also, the Cairngorm sample applications demonstrate some design patterns, such as the Presentation Model and Command, and in these Parsley is used as the underlying IoC container and messaging framework. We do find Parsley to be a mature and extensible framework, but that is not to discount the other frameworks, which offer their own distinguishing features and characteristics.

Cairngorm itself is undergoing a transformation. The committee acknowledges that the important patterns and practices for RIA development can be applied with a variety of frameworks, and IoC containers provide an elegant means. For instance, instead of declaring services in a Cairngorm service locator, one might declare them in an MXML Parsley config class, a Swiz BeanLoader or a Spring ActionScript XML file. Then the service can be injected into the delegates/commands/etc automatically instead of being retrieved though a locator. The mechanism for dependency-inversion has changed, but the separation of concerns and underlying design patterns remain.

So going forwards you can expect Cairngorm to become more focussed on patterns and practices. The Cairngorm Committee won’t seek to compete with all the latest frameworks, but rather to embrace and encourage them. Cairngorm will aim to provide guidance to help enterprises deliver large Flex projects successfully and where possible this will be framework agnostic. This transition is very much in progress, but we hope the result will promote the continuing development of frameworks, from the trend towards inversion-of-control containers, to the emerging modularity frameworks, like Potomac and Adobe Gravity.

I was a good presentation, you made it look really simple. Thanks for the slides and thanks for clarifying on SmartyPants.

Tom

Sam here (author of Dawn), thanks for taking a look at it! I did that talk at FLUG the other night. I popped the slides up here http://www.ziazoo.co.uk/blog/index.php/2009/11/18/dawn-at-flug/

Also Dawn doesn’t rely on SmartyPants, it has its own DI core… but since they are both derived from Guice they look pretty similar

Cheers mate,
Sam

“SmartyPants was the first IoC Container for AS3 on it’s own.”

That may be the case and I have no problem with that statement.

I was referring to the line “[SmartyPants] is the one that started the whole Dependency Injection trend”. If that is intended to imply “for pure AS3″ or “that does nothing but DI/IoC” that is not apparent.

What do you mean they are both DI? Could you please explain?
Cairngorm and PureMCV use Service Locator pattern, they use a registry ( eg. facade in pMVC ) and they retrieve actors (eg. facade.retrieveProxy) which is not too good, because you end up having a couple of singletons that are hard to unit test. DI makes is easier by removing the registry ( so you don’t have to be doing facade.retrieveStuff ) and keeping your classes decoupled.
Have a look here, it’s from the guy who invented the pattern:
http://martinfowler.com/articles/injection.html

If you look in:
Using a Service Locator he states:
“Injection isn’t the only way to break this dependency, another is to use a service locator.”

Many people state that DI is an alternative to Service Locator pattern, therfore I don’t agee that pureMVC and Cairngorm can be called DI frameworks.

That’s exactly what I wrote.
“Basically all the frameworks apart from Cairngorm and PureMVC rely on DI”

SmartyPants was the first IoC Container for AS3 on it’s own.