This content has been marked as final. Show 4 replies
Although this question may be better suited for someone from AC to respond I will try to provide some direction.
I think the ground rules for adding extensions to Cairngorm are pretty simple in that anyone is free to add extensions to accommodate specific implementations of the Framework. However only those which gain wide spread community support and adoption, and more importantly, are general enough to support typical project architectures would/should be considered to get rolled into future releases.
IMHO the power of Cairngorm is in it's simplicity and lack of unnecessary complexity. It is tempting to add additional functionality and patterns such as IoC/DI and so forth however these types of implementations may not be general enough to be considered for widespread adoption.
Hope that helps.
Thanks for the insight Eric. I was actually thinking about application-specific extensions, and not the kind of extensions that would ever be a part of the core Cairngorm framework.
The challenge is that there's no such thing as a typical implementation. Cairngorm by itself is not designed to provide every design pattern that an application needs. What factors should go into my judgment about when and whether to code outside the Cairngorm pattern?
I think I should probably post questions about one proposed extension at a time, so we can discuss case-by-case scenarios.
I agree that the power of Cairngorm lies in its simplicity and that IoC/DI solutions should not be build in. However, to provide this flexibility of allowing us to extend the framework to our own needs, it should be open for extensibility. I think some of the focus on the future of Cairngorm should be on that fact. For instance, provide a ServiceLocator that can be configured at runtime and the ability to hook into several places in the framework like command creation etc.
Great discussion, and I agree completely that Cairngorm going forward should be about making it extensible, rather than the addition of new features. I can see people wanting to plug in their own ServiceLocators and FrontControllers - will make things a lot easier to test for one thing.
In the past, i also dabbled with the idea of a CommandFactory interface, with a very simple implementation shipping with the framework, that does what the FrontController does today. This would let others provide their own specific implementations for their projects.