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