I just tried to create a plugin system as per André Roberge's specification using the Zope Component Architecture. The program which is being made pluggable is a program written by the effbot. I'm sure the effbot will be thrilled. ;-)
This is not exactly the kind of problem domain where you'd expect to need plugins. It's a parser and needs to operate very quickly, and most plugin architectures (including the ZCA) are based on indirections that aren't really optimized to be inside the inner loop of programs that require very high speed. But that said, I suppose it's as good an application as any to introduce plugins into as a demonstration, as long as you're not judging on speed difference between the pluggable version and the original. I didn't measure speed, as I'd never use the component architecture "for real" in this particular program.
After completing pluginizing the application, a few things strike me. First of all, in order to get the ZCA to parse ZCML, it needs a lot of dependencies. We knew this, of course, but it's pretty striking exactly how many are required when you're dealing with this simple of a problem. Here they are:
pytz-2008i-py2.4.egg zope.component-3.4.0-py2.4.egg zope.configuration-3.4.0-py2.4.egg zope.deferredimport-3.4.0-py2.4.egg zope.deprecation-3.4.0-py2.4.egg zope.event-3.4.0-py2.4.egg zope.exceptions-3.5.2-py2.4.egg zope.i18n-3.6.0-py2.4.egg zope.i18nmessageid-3.4.3-py2.4-macosx-10.5-i386.egg zope.interface-3.4.1-py2.4-macosx-10.5-i386.egg zope.location-3.4.0-py2.4.egg zope.proxy-3.4.1-py2.4-macosx-10.5-i386.egg zope.proxy-3.4.2-py2.4-macosx-10.5-i386.egg zope.publisher-3.5.4-py2.4.egg zope.schema-3.4.0-py2.4.egg zope.security-3.5.2-py2.4-macosx-10.5-i386.egg zope.testing-3.5.1-py2.4.egg zope.traversing-3.5.0a4-py2.4.egg
That's just absurd. The publisher? zope.security?
zope.location? We really need to detangle these dependencies this
at some point to make it reasonable for very small applications to use
zope.configuration (ZCML). Most of these dependencies are actually
dependencies of ZCML (
zope.configuration), rather than the ZCA
In any case, on to the actual plugin-ization. To no one's surprise, the resulting plugin-ized version of the application is much more complex.
To actually plugin-ize the app, I made each operator into a named utility using the ZCA, configured via ZCML. The name of the utility is the operator itself. Each utility is registered via ZCML, ala:
<utility provides=".interfaces.IOperator" component=".operators.operator_add_token" name="+" />
One utility is registered for each operator required. Accordingly, the application's tokenize() function now looks up each operator via a utility lookup:
def tokenize(program): for number, operator in re.findall("\s*(?:(\d+)|(\*\*|.))", program): if number: yield literal_token(int(number)) elif operator: utility = queryUtility(IOperator, name=operator) if utility is None: raise SyntaxError("unknown operator: %r" % operator) yield utility() else: raise SyntaxError("unknown operator: %r" % operator) yield end_token()
When an operator is encountered,
queryUtility is run; it will try to
find a named utility (or it won't, and will raise a syntax error).
The utilities themselves are classes. For example, the
operator_add_token utility is defined as:
class operator_add_token(object): """ plugin """ lbp = 10 def nud(self, context): return context.expression(100) def led(self, context, left): return left + context.expression(10)
Note that I changed the application to use a "context" object rather
than module-scope globals to find the
callable, so this definition isn't exactly like the one defined by the
original application, but it still does the same thing.
In any case, all of the operators are defined in the same file
calc.operators). This is just for convenience; they could be
defined all over hell and gone if you liked (you'd just change the
ZCML to refer to a utility component at a different dotted name). And of
course if you included more ZCML (which can cross files too), you'd
could add another operator or override the implementation of an
existing operator. I don't have very much imagination, so I did
neither. You get the point, hopefully.
I suppose this is about the simplest possible example of using the
Zope Component Architecture to create a pluggable application. You
can also define your own ZCML directives (e.g. I could have made the
ZCML read something like
implementation=".operators.operator_add">. You also don't really
need to use ZCML, it's just a shell around the actual component
architecture that makes clear the difference between code and
The result of my toying around exists at http://plope.com/static/misc/calc-0.2.tar.gz . Run "setup.py install" (in a virtualenv, to prevent polluting your system Python with the above libraries) to install it. To run it subsequently, run "bin/calctest" (a setuptools console script).