Dynamic Service Creation in the PyUtilib Component Architecture
The PyUtilib Component Architecture (PCA) is a component architecture in Python that is derived from the Trac component framework. One important extension was to support both singleton and non-singleton plugins. Trac plugins are singletons that are created immediately when the plugin module is loaded (Python is a wonderful language for supporting this type of capability). Singleton plugins are well-suited for Trac, since it is a persistent application, but many other applications need to employ plugins "on demand". Consequently, the PCA supports non-singleton plugins, which need to be explicitly constructed by the end-user.
The PCA is widely used in the Coopr project, and most plugins are non-singletons. Until recently, the PCA did not directly support plugin construction on demand. That is, the user needed to know the plugin class name, and plugin construction was done explicitly by the user. However, most plugins in Coopr can be best described as named services. For example, Coopr optimizers are implemented as plugins and each optimizer has a unique name.
The PCA has recently been extended to support the alias function, which can be used to declare the name of a plugin with respect to a particular interface. For example, consider the following definitions of the MyPlugin and YourPlugin plugin classes:
These plugins are non-singletons, so they are only registered and used if they are constructed. The alias function allows these plugins to be constructed with a factory class that is supported by the PCA. For example:
The CreatePluginFactory class is provided by the PCA, and it provides a functor that manages the creation of plugins whose names are registered with the alias function.
The PCA is widely used in the Coopr project, and most plugins are non-singletons. Until recently, the PCA did not directly support plugin construction on demand. That is, the user needed to know the plugin class name, and plugin construction was done explicitly by the user. However, most plugins in Coopr can be best described as named services. For example, Coopr optimizers are implemented as plugins and each optimizer has a unique name.
The PCA has recently been extended to support the alias function, which can be used to declare the name of a plugin with respect to a particular interface. For example, consider the following definitions of the MyPlugin and YourPlugin plugin classes:
class ITask(Interface):
def print(self):
class MyPlugin(Plugin):
implements(ITask)
alias('my', ITask)
def print(self):
print "My Plugin"
class YourPlugin(Plugin):
implements(ITask)
alias('your', ITask)
def print(self):
print "Your Plugin"
These plugins are non-singletons, so they are only registered and used if they are constructed. The alias function allows these plugins to be constructed with a factory class that is supported by the PCA. For example:
factory = CreatePluginFactory(ITask)
p1 = factory('my')
p2 = factory('your')
The CreatePluginFactory class is provided by the PCA, and it provides a functor that manages the creation of plugins whose names are registered with the alias function.
Comments
Post a Comment