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 am not certain if this is a problem with the version of Zope I have or if it is the way it's supposed to function, but I found some documentation that suggests at least indirectly that it's doing what it's supposed to do. I tried this on another Zope installation that's "cleaner" to be sure something wasn't messed up, and saw the same behavior with a very simple sketch of this theme. I had: /one -methodX -propertyA(1) /two /three -propertyA(2) /four /five http://host/one/two/three/X sees propertyA(2) http://host/one/two/three/four/X sees propertyA(1) There's a pretty good explanation of acquisition here: http://www.zope.org/Members/Hoekstra/ChangingContexts1
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:
/one -methodX /two /threeA -propertyA(1) /threeB -propertyA(2) /four /five ...then http://host/one/two/threeA/four/five will always get propertyA(1) http://host/one/two/threeB/four/five will always get propertyA(2) 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 ;)
Is any object in your acquisition path, a custom object that defines a __getitem__ method?
Nope