Provide an easy way to build a chain of decorators extending the functionalities of the default plugin manager, when it comes to activating, deactivating or looking into loaded plugins.
The PluginManagerDecorator is the base class to be inherited by each element of the chain of decorator.
If you want to customise the way the plugins are detected and loaded, you should not try to do it by implementing a new PluginManagerDecorator. Instead, you’ll have to reimplement the PluginManager itself. And if you do so by enforcing the PluginManager interface, just giving an instance of your new manager class to the PluginManagerDecorator should be transparent to the “stantard” decorators.
Add several responsibilities to a plugin manager object in a more flexible way than by mere subclassing. This is indeed an implementation of the Decorator Design Patterns.
There is also an additional mechanism that allows for the automatic creation of the object to be decorated when this object is an instance of PluginManager (and not an instance of its subclasses). This way we can keep the plugin managers creation simple when the user don’t want to mix a lot of ‘enhancements’ on the base class.
This function will usually be a shortcut to successively call self.locatePlugins and then self.loadPlugins which are very likely to be redefined in each new decorator.
So in order for this to keep on being a “shortcut” and not a real pain, I’m redefining it here.