Technical columnists are paid to discuss their impressions when they experiment with software, but I am having trouble earning my wages this week. I've revisited two object-based open-source web development tools, Lutris Technologies' Enhydra and Digital Creations' Zope, in the past few weeks.
When it comes to which I prefer, there's no contest: Enhydra gets my vote. It's when I try to explain why I prefer Enhydra that I run into problems. As much as I dislike using Zope, it sounds so much better than Enhydra when I try to describe the two. I can't help but feel that if I just used Zope for another week, I'd become a Zope addict. But another week goes by, and I'm just as sour on Zope as ever. The biggest problem with Zope is that there is so little documentation to help a newbie get started. The situation has improved. There are links from the Zope site (http://www.zope.org) that walk you through an introduction to Zope. One good link is http://www.devshed.com/Server_Side/Zope/Intro. For $US15, you can also purchase a Zope tutorial from http://www.beehive.de.
Zope is based on the programming language Python, but you don't need to write Python code to use it. You'll do most programming in Zope with DTML (Document Template Markup Language). DTML is similar to HTML, so it's easy to get started.
Zope is more than an object-based web development tool; it's a web-based development environment. The web-based environment is written with Zope. The downside is that you must edit much of your code in a browser text box. Expecting someone to code that way is considered a human rights violation in most civilised nations. To be fair, there are ways to use your own editor to write the DTML for apps, but you sacrifice the seamless feel of the web environment to do so.
Zope attempts to be OOP (object-oriented programming) to the max. If you want to create an online shoe store, you could start by creating a shoe object based on the Zope ZClass. You would define the object as catalogue-aware, which means you can do things such as sort your database of shoes.
The next step is to define the properties of a shoe object. This is the same as defining the schema for a database table. Eventually you'll add instances of your shoe object, one for each type of shoe. This is equivalent to adding rows to a database table. To do that, click a few buttons and -- presto! -- Zope will generate DTML pages for adding your data. Sort of. Zope creates the basic DTML framework, but you must manually add data entry fields.
Which brings me to the biggest problem with Zope. It has an unnecessarily high nerd factor. Zope is really very basic stuff, but it never seems basic, and too often fails to automate simple tasks. It's as if the designers of Zope got so caught up in making Zope object-oriented that they forgot that real people want to use it. They seem to have deliberately made it a difficult environment for anyone but professional programmers who are already thoroughly familiar with OOP techniques and eager to get cracking with code.
This isn't necessary. It would be easier to understand how to create a data-centric Zope application if the designers simply exposed the similarities between creating Zope objects, methods, properties, and instances with creating database tables, fields, and rows. Zope would not have had to sacrifice its technical prowess to do this. How difficult would it be to automatically populate forms with fields when creating Zope data objects? That's a common feature for comparable products.
Next week I'll tackle Enhydra and try to figure out why I like it so much more than Zope.
Nicholas Petreley is the founding editor of LinuxWorld (www.linuxworld.com). Reach him at email@example.com.