Zope 3 rocks and rolls
I’ve had two real-world experiences with Zope 3 recently, which is a nice change from Plone. One of the basic rules of any development is “don’t fight the framework”, because most frameworks will continue to try to trip you over if you try to go around it. But in one of the projects which I’m involved in, the main developer doesn’t want to do things the Zope way. So we are not using the ZODB, and not using an ORM, although it still is supposed to be object-oriented and hierarchical in use. Of course we end up producing LOADS of code that could be avoided by either an ORM, or even better, by using the ZODB. If we used the ZODB we could probably throw out 90% of the code. The system would probably be faster too. But the thing is, it works. It’s a lot of work and a lot of code, but Zope 3 just gently steps a side and sais “OK, fine, if you don’t want to do it my way, then that’s you problem”. Zope 3 has all the features you need, but the design with aspect-oriented components, is flexible enough to let you not use the features you don’t want. Zope 3 rocks!
So, for another project, a community site, we looked into using Zope3, rather than Plone. There wasn’t that much content management needed, and Plone 3 doesn’t have many community features, so we were looking at not using so much of Plone, and implementing a lot ourselves. Sounded like a candidate for Zope 3. But we did want some basic CMS features, and didn’t want to implement them. So we looked at z3ext, a CMS written in Zope 3.
z3ext turned out to be a bit buggy. We simply couldn’t get the buildout to work. We fixed a couple of bugs locally, but after two-three bugs fixed it still wouldn’t work, and we gave up. The bugs were fixed by the z3ext guys a couple of days later, so don’t let that stop you, from checking it out, but it stopped us…
So we then tried using just some of the (non-buggy) modules of z3ext. I of course wanted to use Grok to speed up Zope3 development. The scaffolding code needed in Zope 3 is especially problematic in the beginning of a project, to get basic things up and running. Turned out that wasn’t possible. z3ext often uses things in modules that requires you to use the latest version of all Zope 3 modules even when those features really doesn’t add any features. If you use z3ext, you have to live on the bleeding edge of Zope 3. Grok, on the other hand, prefers stability. Grok has had problems with that changes to Zope 3 modules breaks all of Grok, so Grok is based on one of the pre-releases of 3.4. Of course, this means you can’t use the z3ext modules with Grok, which is really, really bad.
This is a symptom of one of the major current issues with Zope 3. The basic problem is of course that Zope 3.4 hasn’t been released in a final version. The eggifying of Zope means that some people are basically writing Zope 3.5 before 3.4 has even been released, and that’s a really bad situation. So we gave up on z3ext. I also do not want to live on the bleeding edge where I have to constantly keep track of which exactly which version of zope.app.whatever works with my project. I want a set of modules that is a proper version of Zope, and only switch one module out if there are bugs in it.
So then we fokused on using Grok, and tried to look for useful modules. First we tried lovey.tag. It was nicely documented, with a doctest README, which I started to read, and follow. After a while I realized I should ignore the start of the doctest, and then I came as far as tagging things. But I couldn’t make the tags persistent. I couldn’t figure out how to do that, and the documentation practically avoided to mention this.
And here is another major problem in the Zope 3 world: Religious doctesting. Doctests are great. For testing documentation. They are NOT good for testing the internals of your module. Especially not in a file called README.txt. Please use README.txt (and preferably also other docests) as a documentation on how to use your module, not how it works internally.
The result? We dropped Zope 3 and switched to Plone. Zope 3 is ready for primetime of you like to write everything yourself. It’s not ready of you want to reuse other peoples modules. And that’s not a problem with Zope 3, but the Zope 3 community. We need to work more together, talk more together and figure out common ways of keeping our modules working together and useful for others. And we really need to release a 3.4 final. Now. Stop caring if there are obscure bugs. People are using Zope 3.4 eggs and have been for a long time. It’s stable enough.