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