Today, I started work on bridging two systems together. Both were primarily written by me, but to serve different ends, and both are built on Zope 2. One is an old e-commerce system that has recently undergone some radical improvements that have given it its own basic component architecture. The e-commerce system uses an RDBMS for its data store, and was recently converted to the table gateway model not much different than I documented here in May 2003. The other system is a lightweight and flexible content management system built around the notion of compound documents. Its descended from a few older projects, and the latest incarnation (the most solid one) has its own component architecture based on configurable policies held in policy managers. Policies dictate extended behavior for both resources (documents) and collections (folders), and works with regular Zope 2 folders just by adding a collection policy manager to that folder. The content management system is ZODB based, storing its data as regular objects in Zope's object database.
While the e-commerce system has its own sort of content management for dealing with images and text to associate with products and categories, it had no real way of letting a customer use the administration user interface to add, edit, or otherwise maintain other pages on the system. Even for those of us who work on the system, having to get in and edit a basic page like a privacy statement was sometimes more of a pain than it was worth. The page was just another page template in the system, and it was a minor annoyance mentally separating that content from the templates used to render the store's data.
Since a strong benefit of the component based stylings of each system is that customer specific enhancements can occur in separate Zope Products (a Zope unit of deployment, usually of pieces that fit together to make an application), I decided that it should be possible to make a product that bridged the two, effectively adapting the data model of the content system to the Page Controller based system used as the view/controller layer in administering the e-commerce store. This is a bit of a challenge because the two systems behave quite differently when it comes to data access and administration. The e-commerce system deals with its data model virtually, using table gateways to retrieve and store data and "Managed Item Page Controllers" which act like virtual containers to retrieve data for editing (and they bind other view objects onto that managed data). The content system deals with its data model directly, using skins and a UI Policy to apply different view templates directly to managed content.
Since the e-commerce system can't use skins without some serious re-architecting, I decided that the content system should be more flexible, since skin assignment was already abstracted out into a UI Policy. I was able to update the UI Policy Manager to allow for skinless execution without affecting the rest of the site at all. It just meant that a content editing skin couldn't be applied. But that's OK! That's where this bridge layer comes in - to adapt the content data model to the page controllers of the e-commerce system. And, since the content system's policy based system is so descriptive and broken up into different responsibilities, instead of forcing them all on a single document or container object and its class, it's been pretty easy so far.
This in turn brings about a real sense of joy and accomplishment - that all of these systems that have been building up over the years, whether they stemmed from a customers request or from an internal solution to a nagging problem, are finally coming together as powerful building blocks. That the design ideals we've been working towards as a very small company are finally paying off, enough so that systems that a year or two ago could never live in the same web site together can now snap together if desired.