Friday, October 14, 2005

A visit to the infamous Zope hell

After spending a couple of weeks with my newborn baby I have returned to work and have found a couple of engagements where I have to correct bugs and create new functionality for some pretty big Zope based applications.

I have been working with Zope for years and I like it, but I am now used to what we could call Zope's best practices for web development, which include creating Python products, working exclusively on the file system, testing, using version control, keeping too much logic out of page templates, documenting the system and more (check the bottom of this post for links).

The problem with these applications I'm working on is that they are old school: hundreds of Python scripts and page templates all stored in the ZODB. Lots of the scripts call each other freely and there are also a bunch of javascript generating scripts which sometimes include very important pieces of business logic in them, making debugging and following the flow of the application very difficult for people unfamiliar with the code (myself!).

One of the systems is fairly well laid out and to be fair was developed at a time where information about Zope best practices and Python product development was scarce. The other one, however, seems to be an adaptation of some older system for similar but not altogether equal requirements and the scripts and templates are full of commented-out code and unused logic which make finding out what's going on even harder.

At least they do not include DTML, which I hate, and the scripts and templates are all organized into folders, so it's not the worst case of Zope hell I have seen, but making even simple changes becomes very difficult in systems like these.

After spending some time with these systems, I can see why some people loathe Zope and call it unpythonic (well, they call it other things too but they go against my self-imposed editorial policy). It doesn't have to be like this, though. Here are a couple of links for those who are interested:


At 7:02 AM, Anonymous gabor farkas said...

i am also working with zope at work,
and i have one mayor problem with it:

generally people recommend not to use the ZMI.

this is nice, but using this methodology, simple things become VERY complicated.

something that takes 3clicks in the ZMI, sometimes means to write 10-20lines of code.

and the time spent on this code is mostly spent in looking into the zope internals, and finding out which methods were called by ZMI.

how do you solve these problems?

or, to put this into a different form:

if you should not use the ZMI, why is it there? is it considered obsolete?

At 11:57 AM, Blogger Carlos de la Guardia said...

Gabor, it depends on the kind of project you are using Zope for. A simple web site with a few pages and a couple of scripts (that is, the majority of web sites out there) can certainly be created very quickly using the ZMI.

There are lots of sites for example which simply install Plone, and customize it quickly using the ZMI, with very good results. Use the ZMI if you are essentially assembling a site out of existing components (products) and need just a few scripts and page templates to tie it all together.

For more complex sites and web applications in particular, I really recommend using the development techniques outlined in the documents I linked to.

This becomes even more important if the application you are creating requires the participation of a team of developers, since the ZMI does not offer source control.

At 5:59 PM, Blogger Julian said...

Zope3 is moving the way of making the ZMI redundant. It's one big lesson they've learnt. I'd say it's obsolete, right? Isn't it just a legacy feature that sounded good at the time?

Most web sites should be made on a separate development environment and then deployed to a live production environment. Anyone who doesn't do that probably is doing just a once off site like a quick Plone deployment.

Any more than that and you'll go insane trying to maintain your site, especially across different testing instances.

When I first started with Zope/Plone I worked through the ZMI. I'd set up a test instance and a production instance. I'd write down all the changes I made, to properties, folders, etc... just so that I could replicate it in the production instance.

... Then I realised I was going insane.

You'll still go insane working through the file system but at least you'll waste a lot of time up-front and do things the right way.

At 6:59 PM, Blogger Jeff Shell said...

On the better written through-the-web (python script's in ZODB) application, have you looked into ways of extracting those scripts into file system products, or had any experience doing so?

I did this on one recent project - when writing it initially, it was just easier to write Python Scripts in folders. But I knew that I could still make efforts to make that system usable and maintainable for me as a developer, so I made an effort to keep it structured and kept most of the logic outside of the public side of the web site. From there, I was able to extract the code out into disk based products and install them into the system as sort of 'singleton' type objects, used like CMF Tools. It's not the most glorious object-oriented code - it's more procedural/modular in the style that Python Scripts stuffed in a folder can be - but it is on the file system and under source control and bla bla bla.

With Python Scripts, the path to extracting them out is shorter, as soon as you find a pattern that works for you. My pattern has involved using something based on SimpleItemWithProperties, from CMFCore.utils. It's a good solid and simple base class to use for tool/module like replacements for folders full of Python Scripts.

The other advantage of this system is that - for the most part - you can do it piecemeal and still get to other modules via the paths / acquisition already in place.

Such work takes time, but if you're having to maintain / do new work on an old system, it can be a good technique to apply.

At 7:32 AM, Anonymous alan said...

Thank you for posting those links, Carlos. I'm playing around with Zope/Plone in my spare time and have been meaning to go look for some pointers on coding & organization practices. I don't like leaving ugly projects for other people to maintain.

At 11:12 AM, Blogger Roberto Iza Valdes said...

This comment has been removed by a blog administrator.


Post a Comment

<< Home