Purpose of this document

May 16, 2000. Please send feedback!

Zope offers two distinctly different development "environments": Python Products, and built through the web ZClasses. Though you can certainly use both in a single project, you will likely turn to one or the other as a first step when approaching a new problem. I get the feeling that the folks at DC turn to Python first, whereas I turn to ZClasses.

This document doesn't go into any background about what a ZClass or Python Product is... I think other docs do that well enough. For the sake of brevity, I'll refer to Python Products as "PyProds".

Speed

I believe that PyProds and ZClasses are roughly the same in terms of speed of execution. ZClasses have some wrapper stuff around them, but I don't think there is much (if any) extra code that needs to be executed when calling ZClass methods.

Development Tools

PyProds are clearly at an advantage in terms of development tools. Creating ZClasses and propertysheets, and adding views and methods to a ZClass are certainly very user friendly processes. However, editing code in a textarea has some definite drawbacks. Since PyProds reside in the filesystem, it is very easy to use your favorite editor, CVS, grep and other tools when working with your code.

ZClasses will be getting help down the line in the form of the ZopeStudio Mozilla app. Currently, you can edit your code using your favorite editor if it supports FTP. It also seems possible to create some simple tools that allow you to edit your ZClass code locally, store it in CVS, and send the changes through via XML-RPC or ZClient.

Flexibility

PyProds win in the flexibility department as well. In order to keep evil people from gaining access to your box through your website, through the web components can only do a subset of what Python can do. For example, you can't open files in DTML or a PythonMethod. PyProds live in the file system, and therefore have access to all Python and Zope services. It is also likely to be a lot faster to create a relatively complex object hierarchy in Python than it would be to build it up through the web.

PyProds also have a significant advantage in that they have unrestricted access to different modules, to files in the filesystem, and to the network. For many applications, you need to communicate with the outside world. To do so with ZClasses would probably involve a number of external methods or other Python code that is glued to the ZClass.

A very important flexibility issue with ZClasses is that once you've created the ZClass, there is no guaranteed way to change the base classes. There are apparently some really deep issues behind this. To give yourself the ability to change base classes later on, it is probably wise to create a Python base class for your ZClass and have that class inherit from the appropriate other classes. Then, you can just change that little bit of Python in order to add or remove a base class. This has the added benefit that you can easily make minor additions to your ZClass that would not be possible through the web (such as writing a custom object traversal handler).

Ease of Programming

Once you get into the swing of it, ZClasses are quite easy. Writing complicated DTML Methods is not necessarily a fun thing, but PythonMethods give you a way to avoid complicated DTML and still develop through the web.

PyProds are not as visual as ZClasses for development. You have to remember which methods to call to create your management tabs, etc. But, I don't see this as a stumbling block, because there is not that much to remember, and there are plenty of good examples around to work off of.

On May 15th, Shane at DC released the Refresh product. This eliminated the single biggest reason to not use PyProds: having to restart Zope with each change. Now, you can make your code changes, and just click Refresh to try them out.

Conclusions

With the introduction of the Refresh product, I will probably do all of my serious application plumbing in Python. That gives me complete flexibility, plus the power to use good editors and CVS, which is critical in a multi-programmer environment. We may still use ZClasses for some of the highest level application objects, but we'll definitely use Python base classes. That way, we get the ease of building ZClasses, with the ability to reliably change base classes at will.