4 Replies Latest reply on Aug 18, 2008 5:46 AM by (Alistair_McLeod)

    Extending Cairngorm - What are the ground rules?

      I was wondering what the rules are as far as extending your application's Cairngorm classes, or creating new design patterns between Caingorm pieces.

      What is the recommended practice for addressing custom requirements with Cairngorm? What if I wanted to add an injector between the Model and the View, so that the view does not contain a singleton reference? What if I wanted to add listeners to the FrontController for logging, precondition testing, and other cross-cutting concerns?

      At what point does it become "not recommended practice" for me to tinker with the framework of my Cairngorm application?

      I've been trying to construct a list of definite no-no's in Cairngorm. This way, if we have to extend Cairngorm, we can do so while treading lightly, and embracing the principles of the framework, even when we can't follow the paved path exactly.

      The following link is my work in progress. I'd like to hear suggestions and thoughts.
        • 1. Re: Extending Cairngorm - What are the ground rules?
          Hey Harry,

          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.

          • 2. Re: Extending Cairngorm - What are the ground rules?
            hgarland Level 1
            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.
            • 3. Re: Extending Cairngorm - What are the ground rules?
              Christophe Herreman
              Hi Eric,

              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.

              • 4. Re: Extending Cairngorm - What are the ground rules?
                Hi Guys,

                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.