On Fri, 17 Dec 1999, Dave Parker wrote:
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)
Ok, let's look at the first case. It evaluates to: one.two.three.four.methodX The publisher traverses to one, and then from one to two. It cannot find three.four.methodX in two, so, *in the context of two*, it acquires three.four.methodX. This is basically the same as acquiring methodX directly into two, since methodX is a DTML Method. The fact that you put three/four/methodX in the URL line does not change the context of the acquisition. (Someone correct me if I'm wrong, please.)
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?
It's the physical path combined with the context in which the acquisition is occurring. I think. :)
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)?
ZClasses are contained in a product. So, yes, to use a ZClass, the product that contains it must be installed. ZClasses are "above" the OFS, so to speak.
My trouble has been in imagining what the development cycle for a specific application (not a generic product) would look like in that context.
I am using ZClasses for a specific application. I just make sure they're installed on whatever server is going to serve my app. :) --Jeff