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