[Zope] Acquisition problem - please help

[Dave Parker]

(long quote here required for context...)

"Jeff K. Hoffman" wrote:
> 
> I had this problem, initially, too. Bear with me, here.
> 
> > /one
> > -methodX
> > -propertyA(1)
> >
> >       /two
> >
> >               /three
> >               -propertyA(2)
> >
> >               /four
> >
> >                       /five
> 
> Acquisition is based purely on *physical containment* in the object
> database, not some magic URL. Whether something can be acquired (the
> acqusition path) is based purely on how objects are arranged in the OFS
> and nothing to do with the URL.
> 
> This means that, in your structure, two acquires from one; three and four
> acquire from two; and five acquires from four. No more, no less.
> 
> The acquisition path for three is:
> 
>   three -> two -> one
> 
> and, the acquisition path for five is:
> 
>   five -> four -> two -> one
> 
> > http://host/one/two/three/methodX sees propertyA(2)
> > http://host/one/two/three/four/methodX sees propertyA(1)
> 
> The first case evaluates to the expression:
> 
>   one.two.three.methodX
> 
> This one needs little explanation, as the only acqusition occurring is the
> acqusition of methodX into one.two.three from one. When methodX is
> rendered, assuming it is a DTML Method and not a DTML Document, it is
> rendered within the context of three, and thus sees propertyA(2).
> 
> The second case evaluates to the expression:
> 
>   one.two.three.four.methodX
> 
> In traversing this expression, the publisher first traverses from one to
> two, then from two to three. Since three does not contain four, however,
> we must acquire four into three. Looking at three's acqusition path,
> above, we see that three acquires from two. Since four *is* contained by
> two, we're in luck, and we acquire four into three (from two).
> 
> Now, *in the context of four*, we acquire methodX. Looking at four's
> acquisition path, we see that four acquires from two, which acquires from
> one. Notice that *three is nowhere in four's acquisition path*. Thus, when
> methodX is rendered within the context of four, propertyA(1) is acquired
> from two, which acquires propertyA(1) from one.
[...]
> > From what I can gather (and from testing), the thing I'm doing wrong is
> > that I'm providing a value to fall back on.  If I ensure that there's no
> > default value to fall back on, as in:
> 
> No, this is not true. It is simply a function of physical containment and
> the acquisition path. I hope the above explains why.


Ok, most of what you said rings true, but here's the solution I've
found, and given your explanation it's confusing to me that my solution
works (which it does):

/one
-methodX
	/two
	-propertyA(1)
	/three
		/four
	/five
	-propertyA(2)

http://host/one/two/three/four - methodX sees propertyA(1)
http://host/one/five/three/four - methodX sees propertyA(2)

So the thing that doesn't jibe is that it can't *just* be the physical
path - were that the case what I'm doing here would not work at all,
right?

> Coming from an OO background (C++, Java, and Eiffel), I can tell you that
> thinking of acquisition as inheritance will kill you. Acquisition *IS NOT*
> inheritance. If you want inheritance, use ZClasses.

I have been meaning to look into that.  Aren't ZClasses a function of a
product (so that to use them you have to install your product that you
created using ZClasses)?  My trouble has been in imagining what the
development cycle for a specific application (not a generic product)
would look like in that context.