[Zope] Acquisition and/or Traversal ?

[Dylan Reinhardt]

At 06:51 AM 1/29/2003, D2 wrote:
>Well, several comments :
>in context._setObject() context *is* containment ?

Context is context, oddly enough.

Containment is when one object is a subobject of another.  Think of this 
ZMI hierarchy:

/
+---a/
      - b
      - c

as being equivalent to:

class container:
    def __init__():
       self.b = some_class()
       self.c = some_class()

a = container()

Thus, a *contains* instances of some_class called b and c.


>Can i say,
>that containment is the *real* containment of an object (URI ?)

If by "real" you mean "as set in the ZMI," then yes.

>and context is the object's containment + (eventually but not necessarily) 
>other containments, so in the example above, context is only composed of 
>containment,

No.  Context is determined for each request.  Context is fully dynamic, 
whereas containment is static (between changes, anyway).

>that acquisition is Zope's natural way to find an object or a property,

I would say so.  Saying it's the "natural way" may be a matter of opinion, 
but acquisition is, perhaps, Zope's most characteristic feature and the one 
I rely most heavily upon.


>that objects have properties containing the acquisition parameters and 
>that they are read by the acquisition mechanism (aq_methods),

Objects have acquisition wrappers.  All other methods and attributes are 
actually provided by these wrappers.

>that traversal is a way to pass to acquisition,

You don't really "pass to" acquisition.  Objects have containment the 
moment they are instatiated.  Contextual acquisition is created by each 
request and can be manipulated during the request.

Traversal is a way of manipulating your objects directly.  It is typically 
used when standard acquisition won't be able to find something it 
needs.  Your example of needing to walk back up the tree and down another 
branch with identical folder names would require traversal since 
acquisition alone isn't going to do that for you.


>+---Subsidiary1/
>        +---Products/
>        +---Proposals/
>
>and as an object can't be contained in different objects, i wouldn't be 
>able to use containment-oriented design only.


With the above, you could store the HQ/default items in the folder just 
above Sub1... for both products and proposals.

Another option would be to create folders just above Sub1 called, say 
product_defaults and proposal_defaults and use something like this as the URL:

/product_defaults/Subsidiary1/Products/product_name

That way, a container has been specified which can resolve product_name in 
the event that Subsidiary1/Products is unable to do so.

But that's ugly.  If you are reasonably experienced with Python and are 
feeling a bit more ambitious, it's not that hard to create your own Folder 
object and override implicit acquisition with specific acquisition routines 
for specific types of attributes.  At that point, you can drop 
product_defaults from your URL and put it pretty much anywhere you want.


>In your suggestion, if i want to show all the objects related to Sub1, 
>(Sub1.Proposals, Sub1.Products, Sub1.Employees,etc.) i suppose that i'll 
>have to put in each object a property *subsidiary* containing the id of 
>the subsidiary to wich belongs the object

Each object will have an aq_parent property that will tell you as much.


>  and to use traversal (creating what you call *observer* or *viewer* ?) 
> to reach all the objects in the different containers (Products, 
> Proposals, Employee...). Isn't it ?

Perhaps... your need for traversal depends on the degree to which you want 
to design around containment.

>If that's true, in what direction must i go ? (un)restrictedTraverse and 
>family or something else ?

I'd stick with restrictedTraverse by default and only use 
unrestrictedTraverse the way one might use the Manager proxy role... very 
carefully.

>Out of curiosity, where may i find the meanings of those acronyms HTH and 
>so on ?

HTH = Hope That Helps... and I hope it does. :-)

Some stuff that you may find helpful:
http://www.zope.org/Members/Amos/WhatIsAcquisition
http://www.ccs.neu.edu/home/lorenz/research/acquisition/ExtensionClass/Acquisition.html
http://www.zope.org/Documentation/Books/ZDG/current/next
http://www.zope.org/Members/jim/Info/IPC8/AcquisitionAlgebra/
http://www.zope.org/Members/4am/aq_trees

And for acronyms...
http://www.geocities.com/SouthBeach/Lagoon/9819/acronyms.html

LMKOAP,

Dylan