[ZDP] Zope hierarchy

Rik Hoekstra hoekstra@fsw.leidenuniv.nl
Tue, 18 May 1999 23:14:30 +0001

> Reply-to:      "Tom Deprez" <tom.deprez@village.uunet.be>
> From:          "Tom Deprez" <tom.deprez@village.uunet.be>
> To:            <zdp@zope.org>
> Subject:       [ZDP] Zope hierarchy
> Date:          Tue, 18 May 1999 15:52:16 +0200

> Hello,
> Lot's of questions! But once I understand them,... A great deal will be
> written down in our ZBook!
> Can some Zopist (or all)  help me on this :
> When programming OO, all object descent from a parent. I guess that this is
> the same with Zope and thus Python. I was browsing through the '.py' files,
> but I don't understand much from it; therefor these questions.

Um, this is a bit slippery for me, someone with a 
good grasp of OO terminology may want to correct me. But I'll give it 
a try. As far as I know, in python not all objects descent from 
parents. Objects have types: in python there are list objects, 
dictionary objects, function objects, class objects, string objects, 
tuple objects etc. Object types  are built-in. 
The .py files you have been looking at define classes and functions 
(and other things). Classes may be subclassed and subclasses have 
parents. Particular objects are then instances of a specific class.

To make things even more complicated Zope implements a feature called 
Acquisition, which meaning an object may use methods of another 

> Zope has several products : DTML Document, DTML Method, External Method,
> File, Folder, Image, Mail Host, User Folder, Version, Z Gadfly database
> connection, Z SQL Method, Z Search Interface, Zope Draft. To this, new
> products can be added, e.g. Z Classes, Python objects?


> Seeing at ZClasses, I can find this hierarchy :
> A simple ZClass descents from ZObject.
> If you want a ZClass which can contain several things, you have to descent
> from ZObjectManager.
> Thus, the hierarchy is :
> ZObject
>      !
> -------------------
> !                     !
> normal        ZObjectManager
> ZClass                    !
>                         container ZClass

I don't think this is so. ZObjectManager is a separate class from 
Thus the hierarchy should look like this:

   ZObject         ZObjectManager
      !                     !
 normal         container ZClass

> Can I assume that the other products (e.g. DTML Document) is the same as a
> ZClass? So that it descents from ZObject? (thus DTML Method is a ZClass?)

No. ZClass is a separate product

> Where can we place these products in the hierarchy?

Near the top, though they usually subclass from SimpleItem or 

> Reading the documents, it's sometimes very confusing to see words like Bobo
> (=Z ORB, ZTemplates, ZODB) ,

Zope grew out of a 'marriage' of Bobo and Principia, both products of 
Digital Creations. Zope is their successor. For Bobo/Principia read 
Zope and for Bobo prefixes read Z

Gadfly (??) a separate product: relational in-memory database 
developed by Aaron Watters

> , Principia (=Zope?),  
see above

both something to do with the ZTables product

>, ZODB3 (What's difference between ZODB3 and ZODB). 

ZODB3 is the successor to ZODB, the heart of the coming Zope2

> think they are
> incorporated (or going to be) into Zope.  Can we say that it are products of
> Zope? 

It depends. SOme are Zope products, other are part of the framework

>Where to place them in the hierarchy above? I want to place them in 
> correct manner (schematic overview) in my mind for the rest of my life.
> How can this be done ?

Um, I'll try and make something up tomorrow. For now it is too late. 
FOr a schematic overview of the technical structure of ZODB3 see the 
document by Jim Fulton (on the Zope site) 

> Another schematic overview I want to make is :
> A ZORB searches for the object into the ZODB (Object database). But then?
> What happens if the object is a folder? Is a SQL Method? e.g. I browse to a
> folder object... The ZORB searches for this folder object in the ZODB. If it
> finds it, it looks for the index_html. In the index_html a #in tag is used
> to iterate trough the results of an SQL result. (Thus the ZODB then searches
> for the ZSQL Method in the ZODB ???)
> How can I represent the ZODB?

Think of ZODB as a web of objects.
For the reason of Acquisition (which escapes notions of hierarchy), 
ZODB is difficult to draw in a schema. Once again I'll give it a try 
tomorrow. Now, its getting late.