Zope Concepts and Architecture

The Zope framework has several fundamental underlying concepts, each of which you should understand to make the most of your Zope experience.

Zope Is A Framework

Zope relieves the developer of most of the onerous details of Web application development such as data persistence, data integrity and access control, allowing you to focus on the problem at hand. It allows you to utilize the services it provides to build web applications more quickly than other languages or frameworks. Zope allows you to write web application logic in the Python language, and provides add-on support for Perl. Zope also comes with two solutions that allow you to "template" text, XML, and HTML: Document Template Markup Language (DTML), and Zope Page Templates (ZPT).

Object Orientation

Unlike common file-based Web templating systems such as ASP or PHP, Zope is a highly "object-oriented" Web development platform. Object orientation is a concept that is shared between many different programming languages, including the Python language in which Zope is implemented. The concept of object orientation may take a little "getting-used-to" if you're an old hand at primarily procedural languages typically used for web scripting such as Perl or PHP, but you should be able to get a grasp on the concepts by reading the Object Orientation chapter and by "learning-by-doing" with respect to the examples in the book.

Object Publishing

The technology that would become Zope was founded on the realization that the Web is fundamentally object-oriented. A URL to a Web resource is really just a path to an object in a set of containers, and the HTTP protocol provides a way to send messages to that object and receive its response.

Zope's object structure is hierarchical, which means that a typical Zope site is composed of objects which contain other objects (which may contain other objects, ad infinitum). URLs map naturally to objects in the hierarchical Zope environment based on their names. For example, the URL "/Marketing/index.whtml" could be used to access the Document object named "index.html" located in the Folder object named "Marketing".

Zope's seminal duty is to "publish" the objects you create. The way it does this is conceptually straightforward.

Your web browser sends a request to the Zope server. The request specifies a URL in the form protocol://host:port/path?querystring", e.g. http://www.zope.org:8080/Resources?batch_start=100.
Zope separates the URL into its component "host", "port" "path" and "query string" portions ('http://www.zope.org', 8080, /Resources and ?batch_start=100, respectively).
Zope locates the object in its object database corresponding to the "path" ('/Resources').
Zope "executes" the object using the "query string" as a source of parameters that can modify the behavior of the object. This means that the object may behave differently depending on the values passed in the query string.
If the act of executing the object returns a value, the value is sent back to your browser. Typically a given Zope object returns HTML, file data, or image data.
The data is interpreted by the browser and shown to you.

Mapping URLs to objects isn't a new idea. Web servers like Apache and Microsoft's IIS do the same thing. They translate URLs to files and directories on a filesystem. Zope similarly maps URLs on to objects in its object database.

A Zope object's URL is based on its "path". It is composed of the ids of its containing Folders and the object's id, separated by slash characters. For example, if you have a Zope "Folder" object in the root folder called Bob, then its path would be /Bob. If Bob is in a sub-folder called Uncles then its URL would be /Uncles/Bob.

There could also be other Folders in the Uncles folder called Rick, Danny and Louis. You access them through the web similarly:

        /Uncles/Rick        /Uncles/Danny         /Uncles/Louis

The URL of an object is most simply composed of its host, port, and path. So for the Zope object with the path /Bob on the Zope server at http://localhost:8080, the URL would be http://localhost:8080/Bob. Visiting a URL of a Zope object directly is termed calling the object through the web. This causes the object to be evaluated and the result of the evaluation is returned to your web browser.

Through-The-Web Management

To create and work with Zope objects, you use your Web browser to access the Zope management interface. All management and application development can be done completely through the Web using only a browser. The Zope management interface provides a familiar Windows Explorer-like view of the Zope object system. Through the management interface a developer can create and script Zope objects or even define new kinds of objects, without requiring access to the file system of the web server.

Objects can be dropped in anywhere in the object hierarchy. Site managers can work with their objects by clicking on tabs that represent different "views" of an object. These views vary depending on the type of object. A "DTML Method" Zope object, for example, has an "Edit" tab which allows you to edit the document's source, while a "Database Connection" Zope object provides views that let you modify the connection string or caching parameters for the object. All objects also have a "Security" view that allows you to manage access control settings for that object.

Security and Safe Delegation

One of the things that sets Zope apart from other application servers is that it was designed from the start to be tightly coupled not only with the Web object model, but also the Web development model. Today's successful Web applications require the participation of many people across an organization who have different areas of expertise. Zope is specifically designed to accommodate this model, allowing site managers to safely delegate control to design experts, database experts and content managers.

A successful Web site requires the collaboration of many people people in an organization: application developers, SQL experts, content managers and often even the end users of the application. On a conventional Web site, maintenance and security can quickly become problematic. How much control do you give to the content manager? How does giving the content manager a login affect your security? What about that SQL code embedded in the ASP files he'll be working on - code that probably exposes your database login?

Objects in Zope provide a much richer set of possible permissions than a conventional file-based system. Permissions vary by object type based on the capabilities of that object. This makes it possible to implement fine-grained access control. For example, you can set access control so that content managers can use "SQL Method" objects, but not change them or even view their source. You can also set restrictions so that a user can only create certain kinds of objects, for instance "Folders" and "DTML Documents" but not "SQL Methods" or other objects.

Zope provides the capability to manage users through the web via "User Folders", which are special folders that contain user information. Several Zope add-ons are available that provide extended types of User Folders that get their user data from external sources such as relational databases or LDAP directories. The ability to add new User Folders can be delegated to users within a subfolder, essentially allowing you to delegate the creation and user management of subsections of your website to semi-trusted users without worrying about those users changing the objects "above" their folder.

Native Object Persistence and Transactions

Zope objects are stored in a high-performance transactional object database known as the Zope Object Database (ZODB). Each Web request is treated as a separate transaction by the object database. If an error occurs in your application during a request, any changes made during the request will be automatically rolled back. The object database also provides multi-level undo, allowing a site manager to "undo" changes to the site with the click of a button. The Zope framework makes all of the details of persistence and transactions totally transparent to the application developer. Relational databases which are used with Zope can also play in Zope's transaction framework.

Acquisition

One of the most powerful aspects of Zope is "Acquisition", and the core concept is simply that:

Zope objects are contained inside other objects (such as Folders).
Objects can "acquire" attributes and behavior from their containers.

The concept of acquisition works with all Zope objects, and provides an extremely powerful way to centralize common resources. A commonly used SQL query or snippet of HTML, for example, can be defined in one Folder and objects in subfolders can use it automatically through acquisition. If the query needs to be changed, you can change it in one place without worrying about all of the subobjects that use the query.

Because objects are acquired by starting at the current level in the containment hierarchy and searching upward, it is easy to specialize areas of your site with a minimum of work. If, for example, you had a Folder named "Sports" on your site containing sports-related content, you could create a new header and footer document in the Sports Folder that use a sports-related theme. Content in the Sports folder and its subfolders will then use the specialized sports header and footer found in the "Sports" folder rather than the header and footer from the top-level folder on the site.

Acquisition is explained further in the chapter entitled Acquisition.

Zope Is Extensible

Zope is highly extensible, and advanced users can create new kinds of Zope objects, either by writing new Zope add-ons in Python or by building them completely through the Web. The Zope software provides a number of useful built-in components to help extension authors, including a robust set of framework classes that take care of most of the details of implementing new Zope objects.

A number of Zope add-on products are available that provide features like drop-in Web discussion topics, desktop data publishing, XML tools and e-commerce integration. Many of these products have been written by the highly active members of the Zope community, and most are also open source.

Fundamental Zope Components

Zope consists of several different components that work together to help you build web applications. Zope's fundamental components are shown in the figure below, and explained following the figure.

Zope Architecture

Figure 2-1 Zope Architecture

ZServer: Zope comes with a built in web server that serves content to you and your users. This web server also serves Zope content via FTP, WebDAV, and XML-RPC (a remote procedure call facility).
Web Server: Of course, you may already have an existing web server, such as Apache or Microsoft IIS and you may not want to use Zope's. Zope works with these web servers also, and any other web server that supports the Common Gateway Interface (CGI).
Zope Core: This is the engine which coordinates the show, driving the management interface and object database.
Object Database: When you work with Zope, you are usually working with objects that are stored in Zope's object database.
Relational database: You don't have to store your information in Zope's object database if you don't want to. Zope works with other relational databases such as Oracle, PostgreSQL, Sybase, MySQL and others.
File System: Zope can of course work with documents and other files stored on your server's file system.
ZClasses: Zope allows site managers to add new object types to Zope using the Zope Management Interface. ZClasses are these kinds of objects.
Products: Zope also allows site managers to add new object types to Zope by installing "Product" files on their Zope server's filesystem.