[Zope] Acquisition problem - please help

[Jeff K. Hoffman]

On Fri, 17 Dec 1999, Dave Parker wrote:

> Pavlos Christoforou wrote:
> 
> > Dave this beats me. If M is a DTML Method then it should acquire the value
> > of X nearer in the acquisition path. If it is however a Document or any
> > other object it will start acquiring from its own context in your case
> > first.
> 
> Yeah, it beat me too ;)
> 
> What I believe I didn't understand is that the path acquisition takes
> isn't exactly what you'd think.

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.

> There's a pretty good explanation of acquisition here:
> 	http://www.zope.org/Members/Hoekstra/ChangingContexts1

You should also read:

  http://www.digicool.com/releases/ExtensionClass/Acquisition.html

As Michel said, Jim is a smart guy, so this might make your head explode.
But, it's worth a shot. :)

> 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.

> I do not fully understand this, but I've restructured my site to
> accomodate it, and it appears to be the solution I'm looking for.  I
> think my Smalltalk experience is killing me here ;)

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.

--Jeff