Hi Dylan, Thanks for replying. Dylan Reinhardt a écrit:
At 01:14 PM 1/28/2003, D2 wrote:
Needing a starting point to understand how traversal and acquisition work
As a starting point, about 90% of what you need to know about acquisition can be summarized thus: 1. Acquisition works by containment or context. 2. Containment trumps (precedes) context.
To put this less formally, the relationship defined between two objects in the ZMI is more tightly bound than the relationship suggested by the construction of a URL. This should make a lot of sense, hopefully.
Traversal is mostly a fancy way of building an acquisition context or specifying a particular object to render. Since containment trumps context, it follows that traversal should be thought of as a less optimal way to use acquisition.
I would suggest that containment-oriented design (not traversal) should be your default choice for an acquisition strategy. There are cases that call for acquisition by context and heavy traversal, but containment is easier to design for and more generally useful. In most projects I've done, the need to perform significant traversal indicates that some refactoring may be in order.
Well, several comments : in context._setObject() context *is* containment ? So what is the difference ? (maybe the answer is below) Can i say, that containment is the *real* containment of an object (URI ?) and context is the object's containment + (eventually but not necessarily) other containments, so in the example above, context is only composed of containment, that acquisition is Zope's natural way to find an object or a property, that objects have properties containing the acquisition parameters and that they are read by the acquisition mechanism (aq_methods), that traversal is a way to pass to acquisition, parameters that are not contained in the object's acquisition properties, modifying acquisition's behaviour,
In this example company, a subsidiary must establish proposal based on a product list. If it doesn't have products, it must use the headquarter's ones.
1 with this hierarchy, how can i reach the Product list in the Products Folder from Proposal 1 of Subsidiary 1 ?
Since it sounds like the purpose of your hierarchy is to drill down from general to specific, not to partition different levels of security, what about the following:
/ +---Products/ - item1 - item2 - item3 +---Sub1/ - item1 - item3 +---Proposals/ +---Etc/
The URL: /Products/Sub1/item1 will find the item1 object in the Sub1 folder.
The URL: /Products/Sub1/item2 will find the item2 object in the folder just above Sub1.
The name item2 can't be resolved by Sub1, but *can* be resolved by Sub1's container. Ta da! It works and you're done. Not bad, eh?
This pattern is easy enough to nest if you should need more than two layers, BTW.
That's the way i did it for shared properties such as the company name, headquarters adress, company web site, etc. And it works pretty well. But as there are several ways to organize the hierarchy, +---Products/ +---Sub1/ +---Sub2/ +---Proposals/ +---Sub1/ +---Sub2/ or +---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. 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 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 ? If that's true, in what direction must i go ? (un)restrictedTraverse and family or something else ?
2 If Products weren't folder but objects and items weren't contained objects but properties of Products, would the solution be the same ?
Probably not, the way you have it, unless you specifically designed the objects to work that way.
If an object can't resolve a name, it will look in its container object, in its container's container, etc., and then back up the chain defined by context. It won't be looking for an object named Products (necessarily) that can resolve the method item1, but for *any* object in the acquisition chain that can resolve "item1". You would probably need to give each different Products object a different name so that you could define a "fall-through" acquisition relationship, thus:
/hq_products/sub1_products/item_property
In this example, hq_products is the same type of object as sub1_products... they just have different methods/attributes available.
When item_property *isn't* resolved by sub1_products, you've ensured that there is an object further up in the acquisition chain which *can* resolve the name (assuming the name can be resolved at all). I'm assuming that hq_products is contained by something found in the containment hierarchy of sub1_products. I'm pretty sure you'll have a difficult time pulling this off if you don't give the different Product objects different names... and that's a requirement that may impose significant limitations.
If you're locked into the hierarchy you've defined, you'll probably need to create some kind of "observer" or "viewer" method that traverses your hierarchy in specifically designated ways under specific conditions. This is easy enough to do, but I would suggest that designing your hierarchy to suit your acquisition requirements might be the simpler, faster, and more durable solution.
$.02... HTH
Out of curiosity, where may i find the meanings of those acronyms HTH and so on ? Andre
Dylan
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
-- Andre PZP Enthusiast