I have an RCP application that uses extension points to defined various pluggable bits of functionality.
In some cases, I’ve got an extension point that can logically have many implementations active at a time: say, a DataFeed point, and the application can support many of them.
In other cases, it only makes sense for there to be a single implementation active in a running instance of the application. I do want users to be able to switch between them though, and uninstalling/reinstalling plugins to do so is not very user friendly.
The way I’ve come up with to handle this is to define the extension point as having a factory using IExecutableExtensionFactory, then each plugin has to have a preference to say whether it’s active. If it’s not active, the factory returns null, and the application looks at the next option. If none, then use some reasonable default.
This doesn’t feel quite right though, and I wonder if there’s an alternate approach that I haven’t hit on yet to model this type of behavior. Anyone have ways of doing this that feel better?
In your solution, the responsibility for deciding whether an extension is active or not is assigned to extension providers (the factories). Regardless of the actual logic of choosing active extension (at any given moment) I’d say that it would be better to have the control in extension point provider, that is, in the class that makes calls to the factories. That’s because extension providers don’t know about each other (or shouldn’t know).
This is actually pretty common situation in Eclipse and it is usually solved by having extensions define additional attributes for extension point handler to decide which extension should be active depending on workbench state (see, for example, enabledWhen attribute of org.eclipse.ui.handlers extension point) or user preferences.