Flex app architecture, how can I build component library that can be overriden

Question

Hey there,

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 compenent, 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.

Any ideas on how to build this thing?

Answer 1

No matter what you are going to be changing a reference to a specific class somewhere. You can subclass (using extends) components and then modify their behavior, but you have to change your references to talk to the subclass instead of the parent class.

I would just create a subclass for only those things that you need to extend the functionality of (extend meaning change or add on to in any capacity) and then use those subclasses in place of where you were using the parent class. Its more work, but the easiest and more chance for reusing the code.

Answer 2

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.