[Zope] Acquisition and/or Traversal [correction]

[Dylan Reinhardt]

At 02:41 PM 1/30/2003, D2 wrote:
>Thanks for the links, i had read the DevGuide when i began with Zope, but 
>found it esoteric at that time.
>My knowledge evolving, it's easier to read

It's a big hurdle, that one.  But once you know what it is, the docs are 
brilliant. :-)

>What i understood,
>Containment: the objects' house and the path to the object from the root
>context: the road used to reach the object.
>A property will be searched first in the object's containment, then in its 
>parents ones, to the root. If the containment-search failed, the search 
>will be made in the context.

That's most of it.  The one extra wrinkle is, any object specified in 
context also has its own containment which (IIRC) also precedes objects 
further up the acquisition chain.

>The context may be searched by using basic acquisition or by calling 
>methods on wrappers (aq_inner, aq_chain, aq_parent, _of_, etc. .

I'm not sure if "searched" is the word I'd use, but it sounds like you're 
headed in the right direction.  Also, just FYI, the __of__ method has four 
underscores.  It's a heck of a good trick to know, that one. :-)


>When i want to add a product or a Proposal i use :
>Company/<Department_id>/<Products_or_Proposals/addMethod : the object will 
>inherit of the department properties but will be stored in 
><Products_or_Proposals> that will be the context.

So far so good...

>Departements will be one of the aq_parent of the object.

I'm not sure I follow you here.  If an object is installed in Products, 
then Products will be its parent.

When you call:
Company/department/Products/some_product

then department will be *in* the acquisition chain for some_product, but 
Products will still be its parent.

I might be getting nit-picky at this point... what you've described sounds 
like it could work.  But for the most part, Acquisition needs to be 
understood, not manipulated.  It's rarely the case that you'll use the 
acquisition wrapper methods unless you're developing your own Python 
Products... at which point, your solution would be radically different.

>as i need to have the sub's specific Products + the HQ's Products, i test 
>the 'related_to' and 'belongs_to' properties.

I'm not sure I see how that improves on using a folder hierarchy to group 
products.  Either way you're segregating your products by owner, and a 
folder hierarchy would make that segregation far easier to inspect and 
enforce... also you may run into trouble when you want one version of a 
product for one department but want the rest of the departments to use the 
HQ version.  I'm sure it's quite possible to make your solution feasible, 
but there may be challenges along the way.  But then again, there are 
always challenges, aren't there?  ;-)


>Not too stupid ?

Not stupid at all... but at a certain point, the best way to tell if you 
have a design weakness is to give it a try.  I'd say give it a go.

Happy Zoping,

Dylan