R – Flex app architecture, how can I build component library that can be overridden

actionscript-3apache-flexArchitecture

I've got a rather large flex app that we've just built for a client. Now, the bossman tells me that more clients are interested in the app. However, their implementations will need a few small tweaks (don't they always!).

We're using Cairngorm and from what I can tell thus far, the only things that will be different between clients are the views. Currently the views reside in the main flex application and everything else lives in libraries.

So I took the views (the mxml components) and stuck them in a library so that all the new client implementations can use them. So far so good. So now I create a new Flex application project, reference my new library of mxml components, add them to the main mxml application file and the app works great.

But here's the problem, how do I build this thing so that I can override the behavior in the "default" components with client specific components? What would be great is if I could just add an Mxml file to my client Flex app and the framework knows that it should override the default component. You might say that I could just swap out the component in the main application file, but I need the power to swap out any component, even ones that are deeply nested within other custom components.

In Asp.net you can use a "placeholder" control and then determine at runtime what control to load. But I'm not sure how to do it in Flex.

How to build this thing?

Best Answer

You could solve the problem by using a class factory. Instead of creating instances of new components directly, you would ask a factory class to create the component for you, and based on some criteria (perhaps a static constant value in the Application?) the factory would decide which class to instantiate the component from.

The article and code sample on Wikipedia explains it better than I ever could: Factory method pattern (read on from the "Encapsulation" heading).

Two potential drawbacks with this approach:

  1. You will be adding more architecture to your codebase. In my experience the factory pattern doesn't necessarily make code easier to read. Difficult to read code == less reusable code.
  2. If you rely heavily on MXML you might need even more quirks to instantiate the components from the factory.
Related Topic