Pillars of Python: Zope 2 Web framework

Zope 2: An object publishing system
Zope 2 is touted as an "object publishing system." In fact, the original Zope claims to have been the first object publishing system, a paradigm that other Web frameworks have adopted. For example, Pyramid's "traversal" mechanism for URL mapping was heavily influenced by Zope.

In an object publishing system, the URL determines which application object should be accessed and which method should be called. Consequently, a URL does not reference, say, an HTML or PHP file in a file system; rather, the Web framework peels the URL apart to deduce which functions should be called (and with what arguments) to produce a response. Such a system depends on the availability of a persistent object storage system of some sort. For Zope, that would be the Zope Object Database (ZODB), described below.

In the context of Zope, object publishing works something like this: Your Web browser sends an HTTP request to the Zope server in the form of a URL. Zope separates that URL into its constituent host, port, path, and query string portions. Using the path portion of the request, the Zope server will locate in the ZODB an object responsible for processing that particular URL. Then, based on the execution parameters in the URL's query string, the server will "execute" the object. Typically, when the execution concludes, the object will return a value -- HTML, image data, and so on -- and this data will be passed back to the browser.

Zope 2 employs what is referred to as "through the Web" development. This means that you manage your Zope 2 application -- including writing code, Python as well as HTML -- entirely through a Web-based UI called the Zope Management Interface (ZMI). One nice feature of ZMI is that it provides a preview capability for ZPT objects, but it does represent another development environment you'll have to learn.

Zope 2: The Zope Object Database
The ZODB is the foundation of a Zope 2 application. It provides ACID-compliant persistent storage of all Zope objects (a Zope object being a specialized Python object). All data and executable entities in a Zope application live in the ZODB. The ZODB also supports transactions, so if any operation within a transaction fails, all operations within the transaction fail. Typically, this is used in the context of an HTTP request. If the request succeeds, the transaction is committed; otherwise, it is aborted. You can also explicitly manipulate the ZODB's transaction manager (obtain a transaction object and issue "commit" or "rollback" operations as required), and in that case, you can use nested transactions, as well as permit other databases to participate in a Zope transaction.

ZODB is not a "flat" database, but a hierarchical repository. You can put folder objects into the ZODB, and within those folders you can put objects or other folders. In addition, objects can acquire attributes and behavior from their containers. This is called "acquisition," and this inheritance-like mechanism permeates the Zope system.