Zope

You might have noticed that the title of this blog includes the name Zope, but that I have, thus far, not so much as mentioned Zope. Not to worry, I have been looking into Zope, but it is a big subject, and it's incredibly time consuming to just sit and read swathes of documentation to even get an inkling as to how to work with it.

I do have a couple of ideas for web applications which I would consider writing/rewriting in Zope pretty soon.

I have only looked into Zope 2 so far, because that's what's available in Debian Stable, which is what is currently running on my web server. I am starting to understand some of the things Zope does, but I'm not at this point particularly sure why it does them.

The truly wonderful thing about Zope is the ZODB, Zope's Object DBMS. This was what really attracted me to Zope in the first place, working as I have been with Python CGIs with persistence mainly provided by my session class, which just pickles objects to temporary storage.

ZODB allows you to avoid dodgy object-relational mappers and just store real Python objects. This sounds wonderful, but in practice it's nowhere near this simple and if you have any experience of concurrent programming you will know why. Relational databases these days provide ACID for you quickly and effectively, and they can do this because the operations to perform are passed to the DBMS for it to execute. When operations must be performed in application code and there can't be a way to transparently persist the objects without running into concurrency issues. I couldn't understand how the ZODB was transparently solving these concurrency issues, so I read up a bit further on that subject, and as I understand it, it isn't. You get transactional locking, but the granularity is very coarse, so you need to do your own concurrency programming if you need performance. Happily it looks like there are some utility classes which implement some abstract datatypes in a concurrent way.

Zope provides 'products' which are object systems you can import into the ZODB hierarchy and combine to produce applications. To achieve anything useful I believe you must write your own products, which might manipulate other products (your own, built-in ones, or third-party) within the ZODB to achieve their task. For example, the folder object contains other objects and allows them to be accessed at a sub-URL.

Most of the examples involve DTML and ZPT, templating schemes which, although they could produce XML to plug into XSL if I wanted, just don't really fit the way I work.

There's also a Python Script object which might be useful as glue but is sandboxed quite severely.

At this point I must explain my main reservation with Zope 2. It's that the strategy of constructing object hierarchies by creating and configuring object instances in the ZMI (Zope's web-based administration interface) means that your web application is only stored within the ZODB. It depends on the contents of the database not only for data but code structure. Therefore none of your existing tools will work.

That means, for example, you can't use tools like Subversion to maintain a code repository or create a working copy. Perhaps it's possible to use it to maintain your Zope products, but not your entire web application. If you're already using Subversion, it's difficult for anyone to construct any kind of argument as to why you're better off not using it. ZODB's own versioning is not equivalent. In fact, almost anything you already have a tool to achieve, you must write a script to do in Python, or else do manually with the ZMI.

My other point of issue is that Zope's documentation describes in detail a principle called acquisition, which is really some magic with the Python object model to inherit functionality from other objects, a lot like subclassing, but not. The documentation has not, however, given me the slightest inkling as to what it's for.

I've just been reading a few bits and pieces about Zope 3 which suggest that it might be a more straightforward step, providing the bits of Zope that I do want as libraries without forcing me down a road of total Zopiness which would mean my abandoning of some of the tools that I have come to rely on.