In the Python community, whenever discussing web development, there is always the elephant in the room: Zope. The granddaddy of the web frameworks. Often thought of as something to be avoided at all costs, Zope is little discussed.
Which is interesting, considering that one of the more discussed (perhaps not the most; that award is probably taken by Django, and second place most likely by Flask) modern Python web frameworks, Pyramid, can trace its lineage directly back to Zope (and, indeed, the number of zope.* packages it uses is nonzero).
It’s pretty much accepted in many circles at this point that Zope is essentially “a bad word”; a failure; a complex mess, with no remaining lessons to give; essentially, with no remaining redeeming value making it worthy of consideration.
This is a great shame; Zope has a lot to teach
Component oriented development is, in some ways, a “holy grail” of software development. It’s something that Microsoft has quite wholeheartedly embraced, inventing system after system trying to evolve one after the other into their “one architecture to rule them all.” Microsoft first unintentionally stumbled upon this with Visual Basic’s VBX extensions, which formed the inspiration for COM and OLE. They’ve since attempted to supplant these to some extent with .net; though these days they seem to be turning away from component based development, at least on the desktop, with the WinRT API.
Component oriented development is also found at the heart of Sun’s ill fated Java Beans, and somewhat less ill fated Enterprise Java Beans. It also turns up in somewhat surprising places; Android, perhaps uniquely among mobile platforms, has taken some ideas from component based development systems and run with them (which will be the topic of a future post).
The main lesson of component oriented development, at least in my experience, is that its utility is directly correspondent to how core, how fundamental, how integrated it is into your platform. COM is a major integration point on Windows; it is how you integrate into numerous system services and it, likewise, is integrated into them. Perhaps COM’s biggest feature is that it completely understands the Windows networking model.
People who have experience with Zope may see where I’m going here: Zope* is component based. At every level Zope builds upon some fundamentals laid out in two packages: zope.interface and zope.component.
zope.interface isn’t really anything new; zope.component has the real innovation:
Adapters are quite common in real life, yet they’re not something that has ever really been formalised in programming. They’re a simple concept: Given object A, I need a Y. The documentation illustrates it with a simple power socket example, but the capabilities lie much beyond that.
Zope uses adapters everywhere; from view lookup, to various request processing hooks, to aspects of security and “annotation” (the ability to store ‘extra’ bits of metadata attached to objects). They’re pervasive, and one of the main building blocks of the toolkit. They provide a very simple, very powerful extension system.
Adapters come in two** forms: Single adapters and multi-adapters. Single adapters are obvious: they take an object and return another which “adapts” it; multi adapters are really just an extension of that to take multiple objects. View lookup, for example, is done by multi adapter from a request and a content/model object.
Many would say Zope overuses adapters, and I wouldn’t disagree. In running away from the monolithic design that was Zope 2, they perhaps went too far in the opposite direction; and sometimes tracing some code can involve far too much jumping around from extension point to extension point.. Pyramid, in many ways, could be seen to be “Zope done right”; it will be interesting to see what long term success it attains.
But the point remains: Adapters are very useful, and a tool every developer should have in their toolbox.
* The Zope toolkit and everything based upon it
** Ignoring subscription adapters for the moment; subscription adapters are mostly (but not entirely) related to Zope’s event delivery sytsem.