Welcome to Zope.org

Copyright O'Reilly, 2000. All rights reserved.

This is an early draft chapter from a forthcoming book on Zope, to be published by O'Reilly & Associates. The material has not been through O'Reilly's editorial process, nor has it been reviewed for technical accuracy. O'Reilly & Associates disclaims responsibility for any errors in this draft and advises readers to use the information contained herein with caution.

O'Reilly & Associates grants readers the right to read this material and to print copies or make electronic copies for their own use. O'Reilly & Associates does not grant anyone the right to use this material as part of a commercial product or to modify and distribute it. When O'Reilly & Associates publishes the final draft of this book in print form, the content will be made available under an open content license, but this chapter is not open content.

If you have any comments on the material in this chapter, you should send them to the authors, Michel Pelletier and Amos Latteier, at docs@digicool.com.

Extending Zope

Introduction

If you were designing a web site for tracking job candidates you probably will use a Document object to hold the resume information, and use Properties to keep track of the various bits of information about a candidate that you were interested in. Imagine the need for a Resume object that:

• Acted like a Document to contain the resume

• Had a known set of Properties about the applicant, like avialability and desired salary.

What you have immagined here is a new type of objects. Yes, this can be done with DTML Documents and Properties, but it would be nice to be able to design this object before hand instead of creating it every time. This way, you can just create a new type of Resume object and not have to creat any of the Properties on a Document, the Resume object will allready have those properties because it was designed that way.

Products

Products are packages of related ZClasses. A Product can provides one or more types of objects to Zope.

ZClasses

ZClasses are a way of building new types of objects in Zope.

A class is like a blueprint for objects, when designing a class, you are defining what an object will be like when it is created.

Creating

Basic Setting

Meta Type

The Meta Type of an object is a name for the type of this object. This should be something short but descriptive, like Job Candidate or Resume.

Class Id

This is an advanced field that you do not need to use at this point. The class Id is automatically determined by Zope. If you want this class to replace another class, then you could specify its Id here, but this is rarely necessary.

Base Classes

Base classes define a sequence of classes that you want your class to inherit attributes from.

Constructors?

You usually want to leave this option checked unless you want to take care of creating form/action constructor pairs and a Factory objecty yourself. If you want Zope to do this task for you, leave this checked.

Zope Persistence?

This option should usually be checked unless you don't want your object to be saved in the database. This is an advanced option and should only be used for Pluggable Brains.

JobCandidate Class - Example

Customizing

Methods

Methods define the list of objects that your type of object exposes is instanciated with.

Properties

Properties for ZClasses work a little differently than Properites on Zope objects. In ZClasses, Properties come in named groups called Property Sheets. Each Property Sheets is the usualy Zope property definition View:

          <screenshot>

A Property Sheet is just a way of organizing a related set of properties together.

Views

ZClasses have Views, which are screens on the object that users interact with. These views can either be Methods from the Methods tab, or automatically generated views from property sheets.

Permissions

XXX Ugh...

Distribution

Products created through the web can be distributed easily with Zope's product distribution mechanism.

Tracking Job Candidates - Example

First, let's understand the required information for a Job Candidate:

Name

Pretty obvious.

Email

We want to be able get ahold of the candidate.

Resume

The candidates traditional resume resume.

Availability

The candidates availability.

Desired Salary

The candidates desired salary.

Fields

A list of keywords that describe the various fields the candidates is looking to get into.

Create Product

Create ZClass

Select CatalogAwareness as a base class for next example...

Create Property Sheets

Create methods

Define Views

Define Permissions

Instanciate new Candidates

Bob is your uncle.

Cataloging Job Candidates

Based on previous example.

Hook constructor

Hook edit method

Hook delete

Define policy method

Create Catalog

Instanciate Candidates

Search Catalog

Bob is your uncle

Creating new Base Classes

Clean Design

XXX

Common Base Classes

ObjectManagerItem

All ZClasses by default inherit the behavior of the ObjectManagerItem class. This class defines some common methods that all Zope objects have.

ObjectManager

An ObjectManager is a type of object that can manage ObjectManagerItem objects. The most common kind of ObjectManager is a Folder object. If you want your type of object to contain other objects like a Folder does, then inherit from this class.

Contents Class View

If your class inherits from ObjectManager, then your ZClass object will have an additional Contents View that defines what kind of objects this ObjectManager can contain. This lets you restrict the kinds of objects that your ObjectManager can work with.

Document/Method/File/Image

All of the usual basic Zope objects can all be subclassed from, including DTML Document and Method, File, Image, and just about everything else. Use this powerful ability wisely, because mixing lots of weird classes together can cause complex buggy applications, and lead to hideous, ugly monstrosities of a type of object like the evil catdog!

Copyright O'Reilly, 2000. All rights reserved.

This is an early draft chapter from a forthcoming book on Zope, to be published by O'Reilly & Associates. The material has not been through O'Reilly's editorial process, nor has it been reviewed for technical accuracy. O'Reilly & Associates disclaims responsibility for any errors in this draft and advises readers to use the information contained herein with caution.

O'Reilly & Associates grants readers the right to read this material and to print copies or make electronic copies for their own use. O'Reilly & Associates does not grant anyone the right to use this material as part of a commercial product or to modify and distribute it. When O'Reilly & Associates publishes the final draft of this book in print form, the content will be made available under an open content license, but this chapter is not open content.

If you have any comments on the material in this chapter, you should send them to the authors, Michel Pelletier and Amos Latteier, at docs@digicool.com.