Zope 2 is a member of a growing family of Python-based Web development frameworks that began with the original Zope -- Z Object Publishing Environment -- in 1995, an object-based application server originally called Principia. The Zope family tree has grown to include Zope 2, Zope 3, variants such as Grok and BFG, and several well-known Zope-based Web applications such as Plone, Launchpad, and Silva.
One of the longest-established Web server frameworks in any language, the original Zope is arguably the application that put Python on the map. Zope 2's proud ancestry sits at the heart of numerous successful Web applications, and some of its technology can be found in other Python-based Web frameworks. For example, the BFG Web framework has become the Pyramid Web framework, now part of the Pylons project. (See the Pylons site for more details.)
Zope 2 is compatible with the 2.x version of Python; which precise version depends on the version of Zope 2. The current released version of Zope 2 -- version 2.13, the one I tested -- is compatible with Python 2.6 or 2.7. Zope 2 will run in just about any Web server that supports the proper Python version, though the Zope 2 framework's integrated Web server, ZServer, is recommended by the Zope 2 engineers.
Installation of Zope 2 is easy, provided you follow the instructions carefully. The Web framework has numerous dependencies, but the installation handles them all. And because the database is included, no database configuration is needed. I installed Zope 2 in a virtual Python environment, which has the advantage of isolating the installation from other Python application installations on the same system.
Zope 2 applications can scale almost linearly using the Zope Enterprise Objects (ZEO) clustering solution. ZEO lets you deploy a Zope 2 application across many physical computers without needing to change much (if any) of your application code.
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.
Acquisition is even hooked into Python's inheritance mechanism. For example, when the system attempts to resolve an attribute on an object, the inheritance hierarchy is searched first, followed by the acquisition hierarchy. Consequently, you can define a method on an object and place it in a container. From there, objects in all subcontainers will "acquire" the capabilities of that object. This can be used to make a particular service -- the ability to send email, for example -- available throughout a Zope object hierarchy.
There are basically three sorts of objects stored in a ZODB: content, presentation, and logic. Content objects abstract file system entities such as folders and files. Folder objects hold file objects or other folder objects. File objects hold data such as audio, video, text, and so on. Presentation objects correspond to the "view" component of MVC (model-view-controller) architecture; they operate on content to produce displayable data. Typically, a presentation object will be a Zope Page Template (ZPT) object. ZPT lets you embed into HTML special XML namespace elements that provide dynamic behavior to the rendered page.
Finally, logic objects correspond roughly to the "controller" component of MVC architecture; a logic object performs any processing that is not involved in presentation. Another name for logic objects are "Script (Python) objects," which execute a security-constrained subset of the Python language. The objects are security constrained in that there are some operations they cannot perform; for example, they cannot access files on the file system.
Zope 2 is a "batteries included" Web framework and application server -- you truly get everything you need. The ZODB object database is built in, it has no practical size limit (other than the maximum file size that the host OS can support), and it's safe from SQL injection attacks. Naturally, Zope 2's rich capability comes with additional complexity. Learning this framework will take time.