[Zope] Acquisition and/or Traversal ?

[D2]

Hi Dylan,

Thanks for replying.

Dylan Reinhardt a =E9crit:
> At 01:14 PM 1/28/2003, D2 wrote:
>=20
>> Needing a starting point to understand how traversal and acquisition w=
ork
>=20
>=20
> As a starting point, about 90% of what you need to know about=20
> acquisition can be summarized thus:
> 1. Acquisition works by containment or context.
> 2. Containment trumps (precedes) context.
>=20
> To put this less formally, the relationship defined between two objects=
=20
> in the ZMI is more tightly bound than the relationship suggested by the=
=20
> construction of a URL.  This should make a lot of sense, hopefully.
>=20
> Traversal is mostly a fancy way of building an acquisition context or=20
> specifying a particular object to render.  Since containment trumps=20
> context, it follows that traversal should be thought of as a less=20
> optimal way to use acquisition.
>=20
> I would suggest that containment-oriented design (not traversal) should=
=20
> be your default choice for an acquisition strategy.  There are cases=20
> that call for acquisition by context and heavy traversal, but=20
> containment is easier to design for and more generally useful.  In most=
=20
> projects I've done, the need to perform significant traversal indicates=
=20
> that some refactoring may be in order.
>=20

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=20
context is the object's containment + (eventually but not necessarily)=20
other containments, so in the example above, context is only composed of=20
containment,
that acquisition is Zope's natural way to find an object or a property,
that objects have properties containing the acquisition parameters and=20
that they are read by the acquisition mechanism (aq_methods),
that traversal is a way to pass to acquisition, parameters that are not=20
contained in the object's acquisition properties, modifying=20
acquisition's behaviour,





>> In this example company, a subsidiary must establish proposal based on=
=20
>> a product list. If it doesn't have products, it must use the=20
>> headquarter's ones.
>>
>> 1 with this hierarchy, how can i reach the Product list in the=20
>> Products Folder from Proposal 1  of Subsidiary 1 ?
>=20
>=20
>=20
> Since it sounds like the purpose of your hierarchy is to drill down fro=
m=20
> general to specific, not to partition different levels of security, wha=
t=20
> about the following:
>=20
> /
> +---Products/
>       - item1
>       - item2
>       - item3
>      +---Sub1/
>          - item1
>          - item3
> +---Proposals/
> +---Etc/
>=20
> The URL:   /Products/Sub1/item1
> will find the item1 object in the Sub1 folder.
>=20
> The URL:   /Products/Sub1/item2
> will find the item2 object in the folder just above Sub1.
>=20
> The name item2 can't be resolved by Sub1, but *can* be resolved by=20
> Sub1's container.  Ta da!  It works and you're done.  Not bad, eh?
>=20
> This pattern is easy enough to nest if you should need more than two=20
> layers, BTW.
>=20
>=20

That's the way i did it for shared properties such as the company name,=20
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=20
able to use containment-oriented design only.

In your suggestion, if i want to show all the objects related to Sub1,=20
(Sub1.Proposals, Sub1.Products, Sub1.Employees,etc.) i suppose that i'll=20
have to put in each object a property *subsidiary* containing the id of=20
the subsidiary to wich belongs the object and to use traversal (creating=20
what you call *observer* or *viewer* ?) to reach all the objects in the=20
different containers (Products, Proposals, Employee...). Isn't it ?

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


>> 2 If Products weren't folder but objects and items weren't contained=20
>> objects but properties of Products, would the solution be the same ?
>=20
>=20
> Probably not, the way you have it, unless you specifically designed the=
=20
> objects to work that way.
>=20
> If an object can't resolve a name, it will look in its container object=
,=20
> in its container's container, etc., and then back up the chain defined=20
> by context.  It won't be looking for an object named Products=20
> (necessarily) that can resolve the method item1, but for *any* object i=
n=20
> the acquisition chain that can resolve "item1".  You would probably nee=
d=20
> to give each different Products object a different name so that you=20
> could define a "fall-through" acquisition relationship, thus:
>=20
> /hq_products/sub1_products/item_property
>=20
> In this example, hq_products is the same type of object as=20
> sub1_products... they just have different methods/attributes available.
>=20
> When item_property *isn't* resolved by sub1_products, you've ensured=20
> that there is an object further up in the acquisition chain which *can*=
=20
> resolve the name (assuming the name can be resolved at all).  I'm=20
> assuming that hq_products is contained by something found in the=20
> containment hierarchy of sub1_products.  I'm pretty sure you'll have a=20
> difficult time pulling this off if you don't give the different Product=
=20
> objects different names... and that's a requirement that may impose=20
> significant limitations.
>=20
> If you're locked into the hierarchy you've defined, you'll probably nee=
d=20
> to create some kind of "observer" or "viewer" method that traverses you=
r=20
> hierarchy in specifically designated ways under specific conditions. =20
> This is easy enough to do, but I would suggest that designing your=20
> hierarchy to suit your acquisition requirements might be the simpler,=20
> faster, and more durable solution.
>=20
> $.02... HTH

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

Andre

>=20
> Dylan
>=20
>=20
> _______________________________________________
> 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 )
>=20


--=20
Andre
PZP Enthusiast