[ZDP] Zope hierarchy
Michel Pelletier
michel@digicool.com
Tue, 18 May 1999 17:56:44 -0400
> -----Original Message-----
> From: Tom Deprez [mailto:tom.deprez@village.uunet.be]
> Sent: Tuesday, May 18, 1999 9:52 AM
> To: zdp@zope.org
> Subject: [ZDP] Zope hierarchy
>
>
> 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.
>
> 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.
Simple Zope Objects written in Python typicaly inherit from
OFS.SimpleItem.Item to be a non-container object. If you want your
object to be a container, it is usual to inherit from
OFS.ObjectManager.ObjectManager, if you want your object to be folderish
(or a foldoid, as is we often say) your object should inherit from
OFS.Folder.Folder, which inherits from OFS.ObjectManager.ObjectManager
*and* OFS.SimpleItem.Item.
>
> Thus, the hierarchy is :
>
> ZObject
> !
> -------------------
> ! !
> normal ZObjectManager
> ZClass !
> container ZClass
>
ZClasses are default OFS.SimpleItem.Item objects. It is not necesary to
explicitly use Item as a base class. Otherwise, this is a good diagram
to think of building ZClasses. Note that almost all of the stock
objects that come with Zope are written in Python (including
OFS.ObjectManager.ObjectManager) it might be useful to make this
distinction.
>
> 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?)
> Where can we place these products in the hierarchy?
>
A ZClass object is an instance of a ZClass just like a DTML Document
object is an instance of a Python class, there is no difference to Zope
or to Python. In fact, the thing that you call a 'ZClass' and
manipulate through the managment interface is actually a class *manager*
which manipulates the invisible class underneath it, which is what your
ZClass objects are instances of. You never directly work with the class
which your objects are instances of, this is all done through the class
manager (The ZClass). Since the real class is effectivly invisible, you
never need to know it's down there (unless you were wondering why ZClass
methods have a %20 (a whitespace) after them in their URLs ;) This is
because they must have different names then their 'real' counterparts in
the 'real' class)
>
> Reading the documents, it's sometimes very confusing to see
> words like Bobo
> (=Z ORB, ZTemplates, ZODB) , Gadfly (??), Principia (=Zope?), Catalog,
> ZTables, ZODB3 (What's difference between ZODB3 and ZODB). I
> think they are
> incorporated (or going to be) into Zope. Can we say that it
> are products of
> Zope? Where to place them in the hierarchy above? I want to
> place them in a
> correct manner (schematic overview) in my mind for the rest
> of my life.
>
Bobo is the predecessor to ZPublisher (the ORB, see my previous post on
the definition of 'the ORB'). ZTemplate is the successor of
DocumentTemplate, which is the engine behind DTML (note that
DocumentTemplate does *not* define DTML objects, just DTML, DTML Methods
and Documents are defined in OFS). Gadlfy is an SQL database written in
Python by Aaron Watters that is Open Source and comes with Zope to make
it easy for a user to quickly see the ease in which Zope works with SQL,
it is not a component of Zope. Principia is the predecessor to Zope
(pre version 1.9). The Catalog is a not yet released Product (written
mostly in Python with a ZClass sugar coating) which indexes and catalogs
Zope objects so that they can be searched quickly. ZTables is
commercial package written by us that manages tabular data and their
respective indexes in a very convienient and unique way. ZODB3 is the
third major revision of the Z Object Database, formery known as BoboPOS
(POS means Persistent Object System). All versions of BoboPOS and ZODB
fall under the generic moniker "ZODB".
ZODB and ZTemplate are components of Zope (along with ZPublisher, etc.)
ZTables, Catalog, and almost all others are 'Products'. Gadfly could be
considered a 'bundled addon'.
> How can this be done ?
>
> Another schematic overview I want to make is :
>
> A ZORB searches for the object into the ZODB (Object
> database). But then?
Technically speaking, ZPublisher traverses the object database.
Searching implies 1) an expensive procedure and 2) an indeterminate
result. Object traversal is fast and efficient and has finite results.
> What happens if the object is a folder?
If ZPublisher comes to the end of it's traversal and finds an object and
that object is not a method, it looks for an index_html attribute of
that object and tries to traverse that.
> Is a SQL Method? e.g.
It calls the SQL Method's index_html method, which redirects you to the
manage_testForm method to test the methods operation.
> 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 ???)
Because Folder objects inherit Acquisition.Implicit, they will either
use the SQL method in them, or try to acquire one if one is not
immediately accessable. If one cannot be acquired, they will raise a
404 Not Found error.
>
> How can I represent the ZODB?
>
> Please, reply. Otherwise I can't get further with ZBook. Thanks!
>
Tom, many of your questions are really only truly understandable if you
read and grok the source (and most of my answers come from me quickly
referencing the source to make sure they are correct). There are some
serious techical and detailed things going on here, and I think it might
be best to put off documenting the internal operations of Zope until our
UML documentation effort is fully kicked off. Just to fully apreciate
how complex this can get, go to your lib/python directory and run
python, then
>> import Main, ZPublisher
>> ZPublisher.Main('', d=1)
This will put you in the debugger, and you can step by step (hitting the
s key) walk through how the ORB finds, and publishes an object. The
above python request is identical to getting
http://my.host.com/
there is lots going on here, more than I have yet to fully understand.
Until then, there is still a great demand for simpler user level
documentation. I would focusing much of your efforts of the first few
levels of Zope Zen and powerful user level concepts like Acquisition and
DTML Methods vs. DTML Documents. Trying to create a technical Zope
taxonimy will just be recreating much of the documentation effort we are
working on internally.
Great work so far, BTW.
-Michel
> Tom.
>
>
>
>
>
>
>
> _______________________________________________
> ZDP maillist - ZDP@zope.org
> http://www.zope.org/mailman/listinfo/zdp
>