What is Zope?

Zope is an open source web server with a difference. A typical web server publishes the content of a file, Zope publishes Python objects. For example, when you request http://myserver/lance/doc1 from an Apache/IIS server, the server looks for the "doc1" document in the "lance" directory on the server, processes that file (if necessary) and returns the output to you for display in your browser. Zope requests the "doc1" object from the "lance" folder, asks the doc1 object to display itself and returns the results to you browser. In Zope all pages, folders, scripts, database queries, database connectors, etc. are objects with attributes and methods.

Creating objects

The equivalent of a traditional HTML file or PHP script in Zope is an object. You create a HTML page by creating an object. This process is performed by a web interface (ZMI - Zope management interface). In the ZMI you are presented with a list of types of objects that you can create. During the object creation process, you provide values for the object's attributes (id, title, etc.), Zope instantiates the object and stores this instance of the object in its own database (ZODB). This ensures that the actual instance of the object survives server restarts (object persistence).

In Zope (almost) everything is an object. You create objects to connect to databases, you create objects that hold and execute your SQL, folder objects hold other objects, a catalog object does indexing and searching, scripting code is placed in a script object.

Classes

To extend the functionality of Zope, you can build your own object types in Python. To build your own custom object, all you need to do is create a class that conforms to the Zope framework. Briefly, your class must include a call to a special method that initializes the class in Zope, it must have an attribute that uniquely identifies the objects of this class, a method that adds the object to the ZODB and it must have security declarations.

Security in Zope

Zope performs security checks on objects each time you access an object. The ZMI allows you to associate permissions with roles. Object methods have permissions attached to them. When you call an object's method, Zope checks that you have a role assigned to you that has the permission associated with the method.

Zope marks certain Python code (modules) as being safe to be called in a web environment and others as unsafe. Secure Python code can be used in script objects, unsafe code cannot.

Scripting in Zope

Zope uses the Python language for scripting. The best way to explain scripting in Zope is by example, so here goes. Let's say you would like the user to post some data to the server that you want validated and saved in a database. In traditional scripting systems (PHP, ASP, Perl) you would create a script that does the following:

• Receive and validate the data (we cannot have a customer ordering zero widgets).
• Construct a SQL statement for submission to the RDBMS.
• Protect the SQL statement against SQL injection attacks.
• Setup a database session.
• Execute the SQL statement.
• Tear down the database session.
• Generate a response to send to the user's browser.

In Zope you would create the following objects:

• A database connection object.
• A SQL object.
• A Script object to check that the user does not order zero widgets.
• A Page object to display a response to the user.

In the page object you call the Script object to validate the posted data, then you call the SQL object with the validated data. The SQL object will form the SQL statement and use the Database connection object to get the results of the SQL statement. The SQL object also protects against SQL injection by requiring that the values passed to the SQL object for constructing the SQL statement matches the types set by the programmer. All your page template needs to do is display a result to the user. The Database object creates a pool of connections to the RDBMS on Zope startup, saving the cost of setup and tearing down of the connection on each request. If you need to change your SQL at some stage, you only edit the SQL object - in the traditional scripting all code in the script file is at risk of breaking when you change the SQL code.