Zope's Features

Zope has many, many features. Let's get them all listed here and spend a little time discussing whether the feature helps or hinders web development.

Zope Page Templates (ZPT)

This is, without a doubt, the single most cool thing about Zope. By using ZPT, the web developer can make a dynamic page which is easily edited with an existing HTML editor.

For those of you not familiar with Zope, I've created another page to discuss just how cool ZPT really is.

G7L: This is the single-most must-have feature that a Zope replacement must include.

Handling files as objects

One really nice feature of Zope is that files and directories are just objects. You don't have to do anything special to them to treat them as objects, they just are.

This is especially handy when dealing with image files, for example. You don't have to do anything special or tricky to access the image height or width, as object members can give you this information.

G7L: This is a great feature and I hope we can duplicate it in a Zope replacement.

Tagging files with values

Zope files are objects, and like other Python objects, you can add your own properties to these objects.

For instance, suppose you have a directory of gallery images. Each image could have a description which you would want displayed below the image. You could stick all of the description information in a database and then use the image's filename to look up the description. In fact, this is a pretty standard way of handling this common problem.

However, since it is such a common problem, Zope has built-in a way to add such attributes to files.

G7L: This is a great feature and I hope we can duplicate it in a Zope replacement.

Saving files in a database

Sadly, the way that Zope attaches attributes to files is by not using files at all. Instead, Zope keeps all data (attributes, settings, files, etc.) in a database. In many cases, the difference between keeping the file data in a database and keeping it in actual files is minimal. Your typical web-developer would never notice.

There are a couple major drawbacks with this approach, namely:

  • When a hard drive crashes, the damage is typically limited to a few dozen sectors. You generally lose a few files and the rest of your data remains intact. However, if ALL of your data is in a single database, you will lose the whole shooting match in a typical crash.
  • There's a lot of really great tools out there that can help a developer do his job. However, most of them expect to work on real files. A great example of this is the revision control program subversion. If you don't have real files, then you cannot use subversion. Zope includes some revision control code, but it's a far cry from what subversion can do.

G7L: I understand why the Zope developers went this route, but I would really like a Zope replacement to use regular files.

Web-based editing

The Zope developers have put a tremendous amount of work into making Zope websites web-editable. You can upload files, change file properties, create directories, etc. all from your web browser.

This is pretty handy, but is it a logical direction for the product to go? The most successful products in the open source community seem to be the ones that focus on doing a single task really well. They didn't build an HTML editor into Apache. MySQL doesn't have a GUI built-in. PHP doesn't include a debugger. phpMyAdmin doesn't have a text editor.

I'm not saying that it's impossible to make a tool that does a wide variety of things better than competative products which only do one of those things each, but historically, this does seem to be the trend. Building a lot of stuff like that into a product tends to discourage competition, and in most cases, competition helps evolve better products.

That said, I just don't think integrating web-based editing is needed, or even desired, by your typical web developer. DreamWeaver, like most GUI HTML editors, will FTP the pages into place when you finish editing them. This is the mechanism that your typical web developer uses and is comfortable with. I don't think we should try to change how developers do such things.

G7L: This is a neat feature, but I would rather not build in such a tool into a Zope replacement. If such a tool is needed, I would rather seem competition evolve a great one.

Sessions

Sessioning a standard part of most websites. This functionality is so common that it would be a gross oversight not to include it.

G7L: A Zope replacement must include sessioning.

DTML

DTML appears to have been an dead-end in Zope's evolution. Zope documentation seems to discourage the creation of new DTML pages, but yet, much of the web-based editing tools seem to be based on DTML. What a mess.

G7L: DTML is deadwood and should not be carried over into a Zope replacement.

Permissions

Zope developers have clearly put a large amount of work into Zope's ACL system. It was an interesting idea, and I suppose that it could have added a lot of value to the product, but I think an impartial observer would rate the permission system a failure.

This is a rather big topic and deserves more space to discuss the subject, so I'm going to branch off to a separate page dedicated to discussing permissions.

G7L: Building a permission system into Zope was a neat idea, but I think it should be omitted in a Zope replacement.

Smart URLs

One of Zope's more creative features stems from thinking of each page as an object. Zope uses the browser's URL to represent a method call.

Suppose you had an addressbook object and you wanted to call the Management member AddUser to add in John Doe's contact info. In a language such a Python, you might call:

AddressBook.Management.AddUser(Name="John Doe", Addr="jdoe@some.server")

The Zope developers felt that it might be logical to do this with a web application by calling the URL:

http://my.site/AddressBook/Management/AddUser?Name=John+Doe&Addr=jdoe@some.server

I suppose that's a pretty clever idea, but it starts getting rather ugly when you try to call a method at one URL with data at another! Suppose for a moment that we had image viewer code located at:

http://my.site/Tools/ImageView

and we wanted to call that with an image located at:

http://my.site/Images/Image1.jpg

To access this correctly, we would need to surf up:

http://my.site/Tools/Images/Image1.jpg/ImageView

Yuck. What a confusing mess.

G7L: I strongly recommend we steer away from incorporating this feature in a Zope replacement.

Installed Products

One clever Zope idea was to allow developers to make classes and then instantiate pages as objects of those classes. In Zope you would do this by creating a new product and then creating objects of the product type.

The major short-coming of this idea was that products are identified by only a single name. Suppose you created a Calendar class that acted like a folder. In that folder you might put instances of an Event class that you also created. Guess what! You have now reserved "Calendar" and "Event" in the global namespace. If you try to install someone else's product (a security application, perhaps) and it uses the class name "Event", then the installation will fail. You will have created a namespace collission.

I really like the idea of being able to make pages of different class types, but if we provide this feature then we absolutely have to allow some sort of hierarchial naming for the classes.

G7L: If we allow the installation of products in a Zope replacement, then the naming system must be more sophisticated than Zope currently allows.

Stand-alone web server

Zope was designed as a stand-alone web server. It can be "hooked" to a major web server such as Apache, but it is designed to run alone.

I've always found this to be a rather curious design decision and have wondered why they didn't just compile Zope to run as an Apache mod. I suppose that there must be a lot of overhead in Zope and the designers found that trying to start it up everytime a page is loaded made the system too slow.

Regardless of why, I don't think that making Zope run as a stand-alone web-server was a good idea. Apache has had far more time in the field and is known to be particularly bullet-proof and speedy. If a portion of Zope's replacement needed to stay running as a daemon to make it speedy, then I could understand making it a supplimental daemon which connected to an Apache mod. However, I do not think it is prudent to duplicate all that functionality in Zope's replacement. I suspect the resulting page-serve-rate could only be lower in such a system.

G7L: I think Zope's replacement should be an Apache mod, and not run as a stand-alone web-server which can be connected to Apache. I would be okay with Zope's replacement using a daemon to increase speed.

Built-in SQL

Zope provides a standard interface to access whatever database you have installed on your server.

This is a pretty neat thing, but I can't say whether it's important enough to be worth adding. Python has easy access methods for various databases, but does a standardized interface buy us anything?

Built-in search tool

Zope includes a search tool.

I've never used this tool, so I do not know how much value it adds.

Web server variable parsing

All modern CGI languages parse the web server variables.

G7L: A Zope replacement must parse the web server variables and provide them in a nice format.

Variable casting in forms

Zope supports a neat syntax where the form fields can tell the server what sort of values to expect. The web server automatically casts these fields, which makes the developer's code more clean and streamlined.

G7L: This is a great feature and I would like to see it included in a Zope replacement.

RPC

Zope can support RPC! This is extremely slick.

G7L: This is a great feature and I hope we can duplicate it in a Zope replacement.

Versioning

Zope has a nifty version control feature where developers can group their changes under a version object. What is really slick about this is that all of the changes can be released (or deleted in the case of a failed experiment) at once instead of breaking the website while the code is being edited. The theory is that by using version objects, professional developers can avoid the need for a development server in addition to their production server.

This is definitely a cool idea, but in practice it seems difficult to leverage. The primary problem with Zope's version system is that it locks files instead of allowing concurrent editing by multiple developers. Additionally, to be able to see the version you have created, you have to be logged in. This is a logical requirement, but it makes developing many kinds of pages extra tricky.

G7L: I really like the idea of being able to see changes in progress before they are published. However, it may make more sense to leave hooks for this to be developed in a future version (or via an add-in product). That way we don't delay product delivery on a feature that will not be used by all. Also, it would mean that developers could use the version control tools they prefer instead of having the Zope replacement dictate what tools they can use.

Cache objects

A Zope web-tree can include a cache objects. These objects hold a cached copy of dynamically-generated pages. This can greatly increase the page serving speed when a single page is being served multiple times within the page's cache-life.

G7L: This is a great feature. We should definitely leave in hooks to support such a feature, but I wouldn't want to hold up production before this feature was ready.

What now?

Let's discuss what a Zope replacement should do.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.