If I have a folder structure like this: first second third fourth fifth and first defines a property X and third defines a property X (and nothing else defines proprty X) an first defines a method M And I do http://host/first/second/third/fourth/fifth What value of X would a method M see? The value first set or the value third set? What I'm seeing is this: with http://host/first/second/third, M sees the value that third set with http://host/first/second/third/fourth/fifth, M sees the value that first set I am using "Zope version: Zope 2.0.1 (source release, python 1.5.1, linux2) " Is this what is supposed to happen, or is this a bug that was fixed? I *think* I had it working such that M saw third's value at one point, then I changed the name of the property in question (and all the methods that reference it to reflect that). Now I see what I described above. If this is a bug, is there a work around? Desperate!
On Thu, 16 Dec 1999, Dave Parker wrote:
And I do http://host/first/second/third/fourth/fifth
What value of X would a method M see? The value first set or the value third set?
It depends what kind of method M is (I suppose it can be called inconsistency but it is actually a feature). DTML Methods and I believe External Methods behave different under Acquisition than the rest of the of the Zope objects. They are in effect 'attached' to their immediate Parent object in the Acquisition path. Other object, for instance DTML Documents are 'attached' to Object in which they are defined. Is method M a DTML method? Pavlos
Pavlos Christoforou wrote:
On Thu, 16 Dec 1999, Dave Parker wrote:
And I do http://host/first/second/third/fourth/fifth
What value of X would a method M see? The value first set or the value third set?
It depends what kind of method M is (I suppose it can be called inconsistency but it is actually a feature).
DTML Methods and I believe External Methods behave different under Acquisition than the rest of the of the Zope objects. They are in effect 'attached' to their immediate Parent object in the Acquisition path. Other object, for instance DTML Documents are 'attached' to Object in which they are defined.
Is method M a DTML method?
Yes it is. I've got a rather involved framework going, and I'm trying to add some "polymophism" to it thus: <dtml-in "_.getitem(mainMenuItemsMethod,0)(REQUEST,_,_.None)"> mainMenuItemsMethod is the property X I was speaking of. So I'm doing indirection on it; get a list from whatever is described by mainMenuItemsMethod.
Dave Parker wrote:
If I have a folder structure like this:
first second third fourth fifth
and first defines a property X and third defines a property X (and nothing else defines proprty X) an first defines a method M
And I do http://host/first/second/third/fourth/fifth
What value of X would a method M see? The value first set or the value third set?
What I'm seeing is this:
with http://host/first/second/third, M sees the value that third set with http://host/first/second/third/fourth/fifth, M sees the value that first set
I am using "Zope version: Zope 2.0.1 (source release, python 1.5.1, linux2) "
Is this what is supposed to happen, or is this a bug that was fixed? I *think* I had it working such that M saw third's value at one point, then I changed the name of the property in question (and all the methods that reference it to reflect that). Now I see what I described above.
I've tried on a couple other Zopes to make the simplest case work and can't, so I must have imagined that I had it working at all. But I don't understand this - I thought properties and methods were supposed to be acquired this way? Really desperate, please help Dave Parker Sr. Software Engineer GlobalCrossing
On Thu, 16 Dec 1999, Dave Parker wrote:
What I'm seeing is this:
with http://host/first/second/third, M sees the value that third set with http://host/first/second/third/fourth/fifth, M sees the value that first set
I am using "Zope version: Zope 2.0.1 (source release, python 1.5.1, linux2) "
Is this what is supposed to happen, or is this a bug that was fixed? I *think* I had it working such that M saw third's value at one point, then I changed the name of the property in question (and all the methods that reference it to reflect that). Now I see what I described above.
I've tried on a couple other Zopes to make the simplest case work and can't, so I must have imagined that I had it working at all. But I don't understand this - I thought properties and methods were supposed to be acquired this way?
Really desperate, please help
Dave Parker Sr. Software Engineer GlobalCrossing
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
First my apologies for pressing the send button too fast. On Thu, 16 Dec 1999, Dave Parker wrote:
that reference it to reflect that). Now I see what I described above.
I've tried on a couple other Zopes to make the simplest case work and can't, so I must have imagined that I had it working at all. But I don't understand this - I thought properties and methods were supposed to be acquired this way?
Really desperate, please help
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. Is any object in your acquisition path, a custom object that defines a __getitem__ method? Pavlos
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
On Fri, 17 Dec 1999, Dave Parker wrote:
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 was curious enough to try it out and for me it works as I expected. If method X is a DTML Method I always get propertyA(2) as long as the third folder appears in my acquisition path. However if X was a DTML Document then I would get propertyA(1) in all cases. Once I thought acquisition results depended on the phases of the moon ... Pavlos
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
(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.
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
"Jeff K. Hoffman" wrote:
It's the physical path combined with the context in which the acquisition is occurring. I think. :)
That sounds more like what's going on (and helps - thanks).
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. :)
Yeah, I presumed the "must be installed" issue ;) I'm wondering about the underlying mechanism: when you create an instance of a product, how does it relate to the product itself? Put another way: when I make changes to the product, do I have to re-install it to get those changes to kick in?
On Fri, 17 Dec 1999, Dave Parker wrote:
"Jeff K. Hoffman" wrote:
It's the physical path combined with the context in which the acquisition is occurring. I think. :)
That sounds more like what's going on (and helps - thanks).
Cool. I will try and do a semi-formal How-To on my recent research into acquisition and put it up on Zope.org.
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. :)
Yeah, I presumed the "must be installed" issue ;) I'm wondering about the underlying mechanism: when you create an instance of a product, how does it relate to the product itself? Put another way: when I make changes to the product, do I have to re-install it to get those changes to kick in?
Speaking abstractly, a ZClass determines the "template" that all instances are made from. In technical terms, all of the instances "inherit" (for lack of a better word) the attributes of their ZClass. If you put an object (say, an Image) in your ZClass, that one single instance of the image is shared across all instances. In Java terms, these are like static, or "class level" attributes. By default, the only permission given to class attributes is "View", so that instances cannot modify shared attributes (though this can be changed in the "Define Permissions" tab.) If you want each ZClass instance to have its own instance(s) of a particular class, you can use the ZClass constructor to construct instance attributes inside the instance itself. As far as I know, this means that when you update your ZClass and change the way instance attributes are created (via the constructor), you must re-create all of your instances. There might be a better way of doing this sort of thing, but I haven't had the time to look into it, yet. I have found that using ZClasses and acquisition, in combination, I can achieve most of the designs my OOA&D background permits me. --Jeff
Dave Parker wrote:
/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?
It isn't *just* the physical path, but that does have an effect. As long as you proceed from container to contained, acquisition simply looks back up the path. The moment you acquire something from above the current container, you effectively bring in the context of the acquired object. Let's break it down using 'of' for acquisition parents, and brackets to indicate that a name includes its context: /one -> [one] -> one /one/two -> [two] -> two of [one] ... and now it gets a little tricky ... /one/two/three -> [three] of [two] -> (three of [one]) of [two] /one/two/three/four -> [four] of [two]* * Not quite accurate, it's really four of ([three] of [two]), but don't worry about it Since methodX is a method, it doesn't add any context, so PropertyA is searched for in [four] of [two], and found in [two]. /one/five -> [five] /one/five/three -> [three] of [five] /one/five/three/four -> [four] of [five] and PropertyA is found in [five]. Now, if 'three' had a 'PropertyA', both of the above would have found that first in [four] (/one/three/four), so to get the same results you would have to rearrange your URLs into '/one/three/four/two' -> [two] of [four] and '/one/three/four/five' -> [five] of [four]. Not to mention, if you replace methodX with DocumentX and try to put a default 'PropertyA' in 'one' then no force in the world can save you, since: /.../DocumentX -> [DocumentX] of (...) -> (DocumentX of one) of (...) ...and you'll always search 'one' before any other folder. If you really want a default, you need to put it a folder (such as 'three') which is *not* in [two] or [five], but *is* in [three], and ensure that 'three' appears earlier in your URLs than 'two' or 'five'. Clear? <wink> Cheers, Evan @ 4-am
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 is not true. It depends on whether you are using a DTML Method or a DTML Document for methodX in Dave's case. A DTML Document will always find the property in folder 'first', but not in the case of a DTML Method. Pavlos
On Fri, 17 Dec 1999, Pavlos Christoforou wrote:
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 is not true. It depends on whether you are using a DTML Method or a DTML Document for methodX in Dave's case. A DTML Document will always find the property in folder 'first', but not in the case of a DTML Method.
I didn't mean to convey it was. A little ways down, I mentioned the DTML Document / Method distinction:
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).
Sorry. --Jeff
participants (4)
-
Dave Parker -
Evan Simpson -
Jeff K. Hoffman -
Pavlos Christoforou