Portrait of Edd Dumbill, taken by Giles Turnbull

Subscribe to updates

Feed icon Atom or RSS

or get email updates

What I make

expectnation
a conference management web application


XTech Conference
a European web technology conference

Sticking with it -- Zope

I started off the "sticking with it" series last week, covering technologies that others shunned but I stayed with, with a brief description of my use of GNOME. This week I want to pay tribute to Zope, the Python-based web application server.

I first came across Zope before it was open-sourced, and was known as a Bobo and Principia. I played with it a bit, but then moved on as I didn't understand it, and it was still a commercial product. However, there was some lurking appeal that stayed with me. So when these products were open-sourced and became Zope, I was interested.

I started working with Zope in 1999. At the time I was still very much into using PHP for developing web sites. Major sites I'd made in the past such as XMLhack and Pharmalicensing were all PHP driven. Zope, however, embodied a long-held web development dream of mine....

Come with me to a world before XML, if you will. Back in 1995 or so, I was working for the UK's news agency, the Press Association, developing content driven web sites. One of the technologies I helped evolve there was called "inserter."

Inserter was basically a flat datafile and template format, pretty much the same as XML and XSLT is now today, apart from the fact that the dominant data structure in inserter was arrays rather than trees. We did a heck of a lot with this technology: it enabled us very early on to shift production template development away from programmers. It got us a big lead in the UK news site stakes: we were doing with zero extra people what the Times, for instance, took a staff of 18 to do.

For all that, though, there was a problem: the master stylesheet had to contain all the various components the production staff might need. They switched these on and off by changing variables. So at the top of the tree there still needed to be a skilled programmer, who ended up maintaining a pretty monolithic creature. What I really wanted was a system where reusable components could be deployed independently of a master template, and be glued together as needed. I never got the time to do this at PA.

When I saw Zope, I realised that it was pretty much my dream come true. Zope's huge advantage is the way that functionality can be deployed in reusable "products" that can be dropped into a site. For example, navigation elements. Then I hit the other side of Zope, the steep learning curve! In the earlier days, however much you admired the ideas behind Zope, the learning curve hit you hard. Still, there was enough of value to me there, as well as a friendly and helpful community, and I put Zope to work.

My first use of Zope in production was this web site you are reading, usefulinc.com. It was written with the technologies available in Zope at the time, so would likely be considered naive and primitive nowadays. I also got involved in writing a couple of Zope products myself, for RSS 0.91 and the then-hip internet bomb Deepleap.

Since that time, there has been a lot of new stuff in Zope. The old fashioned template markup language, DTML, has been superseded by page templates, which can be edited in tools like Dreamweaver, enabling non-programmers to participate in the creation of Zope sites. The common content management use-cases have been recognized in the creation of the Content Management Framework, a bunch of easy to use add-ins for maintaining portal-like content sites. The CMF has further enabled projects like Plone, that really are sophisticated "out of the box" products.

So why is Zope something that merits a place in a "sticking with it" series? Well, it's not always been the most stable of systems, nor the most CPU-efficient, though I'm glad to say that I've found Zope 2.6.0 very satisfactory in both these regards.

One of the unfortunate side effects of putting all the content into an object database is that it can be lost more easily (just delete one file!) and that errors aren't as easy to track down as they are with the file system. Zope also needs some non-trivial care to get right in a high load production environment. Additionally, for the newcomer, Zope's most powerful and pervasive concept, acquisition, can take quite a lot of getting used to.

However, I can truthfully say that my investment in Zope has been well rewarded. This blog, for instance, was pretty trivial to set up on top of the current framework I had already created. Each entry is simply a document sitting in the database. The blog look and feel is created by the BlogFace product, which orders the items on their metadata. If in future I wanted to restructure and redesign, it's just a case of new queries. None of my data is forever locked in, I can recover it in XHTML whenever I want.

Zope's not a short-term hack. It is something you need to spend time with, and grow to love. It has proved it won't disappear overnight, and that there's a large community concerned with its future.

I've not written nearly as much as I wanted to about Zope here: it has many fine features that I would like to extol (here's a few of them: WebDAV support, through-the-web administration, pervasive metadata, undo support). I hope you'll forgive me this omission and head over to the Zope site to find out for yourself.

Zope is one of a very small number of today's technologies that make me happy.

blog comments powered by Disqus


You are reading the weblog of Edd Dumbill, writer, programmer, entrepreneur and free software advocate.
Copyright © 2000-2012 Edd Dumbill