Who this document is for

If you've done any web development with an HTML-embedded language, transitioning to Zope can be a bit difficult, because the ways of doing things is so different.

HTML-embedded languages are things like Java Server Pages (JSP), PHP, Cold Fusion, and Active Server Pages (ASP). This is a document for helping people experienced in that paradigm start to think in a Zope way.

What's an HTML embedded language?

An HTML-embedded language is where some programming language is inserted into an HTML file to give it dynamic performance. When the page is served, the server runs the code, puts the results in place of the code, and sends out the rendered HTML. (Or it could be the other way around: Java Servlets are best described as HTML embedded in Java, and JSPs are Java embedded in HTML that is compiled into a servlet at runtime.)

Embedded languages usually use external relational databases (like PostgeSQL, MySQL, or Oracle) for persistent data storage.

The Big Differences

A lot of the differences between Zope and HTML embedded languages are also present in the simpler systems they evolved from. See the Zope for Filesystem-based Web Developers zNode for these.

In broadest terms, what these approaches do is put a programming language inside HTML to create dynamic web sites. What Zope provides, on the other hand, is a data model and ways to translate that data to HTML. (In a HTML embedded language, the data model is in the database and implicit in the code.) Zope also provides a lot of the services that often have to be custom built with other approaches.

Acquisition and site structure in Zope have no parallel or comparable feature in HTML embedded languages. Generally the only link pages have to each other is through the back-end database.

For the programmers in the audience: The difference between Zope and HTML embedded languages is akin to the difference between procedural and object-oriented languages. In one you connect static constructs with other static costructs, using a hard to change and fairly flat data model. In the other, you have data structures that can be very adaptable and where relationships within the data structure define a good deal of the logic of the program. I think you can guess which is which.

Where logic goes

In an HTML embedded language programming logic ends up among the HTML pages of the site. Without a disciplned development model, HTML embedded projects can quickly descend into what is lovingly called spagetti code. Changing the appearance of a page turns into an exercise in changing the logic of the site, and in a quickly iterative design process this becomes a substantial barrier to progress.

Usually no structural remedy to this exists, just a procedural one. Adding people to the project is also slow, since site design exists only within the developers' heads.

Zope tries its best to keep logic and presentation separate. Displaying data in HTML form is usually accomplished through a template, which provides a (hopefully) unobtrusive and simple means of displaying data.

The most flexible template type (DTML) has some limited abilities to do logic, meant to provide power in display. It is possible but difficult to write Python code in the template, but no facilites are provided to embed blocks of Python or anything else in the code.

The successor to DTML, Zope Page Templates (ZPT) makes the distinction between logic and presentation clearer, and cleans up some of the fundamental issues with DTML. There is no code allowed in ZPT, and they should work better with HTML editors than DTML, since there are no special tags, only HTML attributes.

So if we're not allowed to or heavily discouraged from putting logic in display code, where does it go? Zope provides several avenues for logic encapsulation:

• Structure. Like designing an object-oriented program, a lot of the logic in the system is inherent in the relationships between objects. But in Zope you have both acquisition and inheritance to use.

  For example, if you want to have the same set of data in several categories, you don't need to add an attribute for its category or create a table that has a list of ids of things in that category. Just create different folders and file them away however you like.

• Objects. A lot of Zope functionality is contained in the objects that various products define. A number of useful objects ship with Zope, and even more can be gotten from third parties. You can even write them yourself. Objects can contain data and behaviour, and using them hides a lot of complexity. Most objects, for instance, come with behaviour for displaying themselves in HTML, which can be a pretty complex operation.
• TTW scripts. When you need logic for manipulating objects, you can use through-the-web scripts. These are currently available in Python and (somewhat experimental) Perl flavors. Other types may be available in the future. These scripts are a somewhat new addition to the Zope core, and along with ZPT are meant to help clean up the logic/presentation separation.
• External methods. Python modules can also be written on the disk of the host system (like most Products) and used in Zope with External Methods. Since greater security credentials are necessary to access the disk, External Methods can do more than TTW Scripts, like call arbitrary Python modules, access the disk, etc.
• Remote methods. Zope objects can also be used with remote procedure calls through protocols like XML_RPC and SOAP. Anything that can do this can control Zope, or be controlled by Zope, making it much more than a web server.

Data storage and access

Zope can and often does access data from external relational databases, but if you're developing a pure Zope application, it's best (with a few exceptions) to stay away from databases. In the HTML embedded language model, databases are the only means of persistent storage, but Zope comes with another means that better fits the Zope model.

Zope ships with an object database called the Zope Object Database (ZODB). It is meant to provide persistent storage for Python objects, since Zope objects are Python objects. Zope is really only concerned with interacting with the ZODB, and doesn't care how it actually stores data, so the ZODB can be backed by a relational database, another ZODB, or any other concievable scheme. By default, the ZODB stores its data in a file called Data.fs on the host filesystem.

The ZODB is a database, and a good one, and it makes a lot of sense to store data in Zope objects on the ZODB, rather than in a database. An object database doesn't work like a relational database with tabular data, but rather stores objects.

This means that everything resides in (logically, and usually physically) the same place. There is no filesystem/database separation like in an HTML embedded environment. Zope makes little distinction between data that displays information and data that stores information. This can be very powerful, since you can interact with templates programmatically if you want.

Visualization

A Zope application is what UI engineers might call "discoverable". Since so much logic is in the structure, it makes sense to display it visually, which is what the Zope Management Interface (ZMI) does. Rather than reading database schemas and code embedded in HTML, you can browse the structure of a Zope site, and quickly gain an understanding of the site. Discovering deeper functionality requires knowledge of the interfaces of the objects involved, and usually little else, since walking through program flow is fairly easy.

When is HTML embedded development better than Zope?

Very rarely, from a technical point of view, although I'm open arguments to the contrary. There are no significant differences in speed or other resources, and Zope is at least as good at integrating with legacy resources as most of the HTML embedded languages. The Zope feature set is at least comparable, and usually better, although there are certainly areas where other products are more developed.

There are other reasons you might not want to use Zope.

• Your infrastructure is already built in something else, and/or your people already know something else. Sometimes the transition costs are higher than the benefits. However, Zope is an excellent "puzzle piece", and can really save on long-term costs. And its always been my position that if your people are good, they shouldn't have a real problem changing. It their skills are really that fragile you have deeper problems.
• You really like your existing development tools. Since HTML embedded files ususally live on the filesystem and Zope objects usually don't, you might end up wishing for your favorite editor, or CVS, or some such tools. This is a valid but aging argument, since Zope can be largely accessed with FTP and WebDAV tools, which are increasingly supported by development tools, and can also be made to look like local files. Mount davfs and say "grep, here I come!"
• Business reasons. This is usually a cover for something like vendor lock-in, timidity over open source products, or some other inertia. Happily, Zope has the answers to most of the tough questions, so a little research and a demonstration of the power of Zope can punch holes in these arguments.

The Road to Zope Mastery

Obviously you're not going to be a Zope master overnight, and it'll take a while before the Zopeish thing to do is aparent. To get there from a HTML embedded development there are a few things to especially keep in mind:

• Logic does not go in presentation. If you think about doing something like adding objects in a DTML Method, scold yourself and do it in a Python script. Better yet, use ZPTs, which won't let you do it in the first place.
• Data is best kept in the ZODB, where you can use it more handily. Only if you require a high percentage of writes to reads or if the data is already out there should you use an external relational database.
• Use objects. If you start thinking about tables or schemas, stop it and try to figure out how objects and object relationships like containment or acquisition can solve the problem. This also means looking for ways to solve problems with structure rather than logic: Don't test for existence of an object and display an error it it isn't there. Put the error in an object of the same name in the parent folder. The error will show up when there isn't an object of that name in the child folder.
• Let objects, scripts, and methods factor out and encapsulate functionality for you. It will increase usability and be a lot easier to understand.

Parting Words

Translating between paradigms as different as Zope and HTML embedded languages can be difficult, and make it seem as if your brain is melting. Zope is known to have a steep learning curve, so stick with it. Read the zNodes, the Zope Book, the mailing lists, the Zope.org Howtos, Zopelabs.com, et al., and experiment. You'll have the Zope Zen before you know it.

Good luck Zoping.