Hi, I've been trying to piece together a site which exploites acquisition, but I have come up against a problem. This basically boils down to the chosen method for acquisiton. I can have a site with the following structure: / +- foo | +- stuff | +- etc... +- bar | +- more stuff | +- etc... +- baz +- and so on where foo, bar and baz are folder objects, which contain various methods, etc. Now, I can construct urls such as: /foo /bar /baz /foo/baz /bar/baz ... and in each of these the child will operate within the context of the parent. At least that is how I would like it to work. But, having read the AcquisitionAlgebra, http://www.zope.org/Members/jim/Info/IPC8/AcquisitionAlgebra/siframes.htm and a post to the list a while back, http://zope.nipltd.com/public/lists/zope-archive.nsf/ByKey/4C6995D8A903E711 I have learnt that acquisition works on the principle of containment before context. Unfortunately this is exactly what I don't want. I want context before containment, because that is the whole reason that I am construction urls in this way. The only reason that foo, bar and baz are all contained in / is so that they will all be available within the context of each other (the wonders of acquisition), but once they have been acquired, the context is all-important. Imaging that baz produces a set of data. Imagine also that within the context of foo or bar only certain subsets of baz's data are relevant. So I could go to /baz and see all the data, or /foo/baz and see only the data relevant to foo. But because of "containment before context", if I have a property as an atribute of foo to let baz know which data is important, baz will ignore it, because there is a property as an attribute of / to define the global case, which baz will use. Why is this? In http://www.zope.org/Members/Hoekstra/ChangingContexts1 it states that PARENTS is defined as the acquisition parents of an object. But this is not true. The acquisition parents of baz are / alone, but if I evaluate PARENTS from the url /foo/bar/baz/foo I will get parents of foo, baz, bar, foo, /. This is inconsistent with the idea of containment before context, and yet this is, in my opinion, the more useful case. Asuming that acquisition works the way that it does and that it is right that it should work that way (although I could be missing some reason as to why that is best), is there some other way by which I can acquire properties by, effectively, the context route? Either way, any feedback would be most welcome. Cheers, Stephen -- Stephen Harrison stephen@nipltd.com New Information Paradigms www.nipltd.com
I have paraphrased your example at http://www.zope.org/Wikis/zope-dev/AcquisitionFeedback We are considering providing some way for you to acquire properties in the way you expected. You can read more about this in the pages connected to the AcquisitionFeedback page. ----- Original Message ----- From: Stephen Harrison <stephen@nipltd.com> [snip]
http://www.zope.org/Members/Hoekstra/ChangingContexts1
it states that PARENTS is defined as the acquisition parents of an object. But this is not true.
PARENTS is the list of objects traversed to get to the *published* object. If you visit "/foo/bar/foo/bar/baz", then PARENTS will contain [bar, foo, bar, foo, /]. If baz calls another method, PARENTS is unaffected, as are the URLn and BASEn variables. Only absolute_url() is affected. The only way (right now) to search for a property in the order PARENTS mentions them is to do so explicitly, by looping through the elements of PARENTS and checking their 'aq_explicit' for the property. Example Python snippet: for p in REQUEST['PARENTS']: if hasattr(p.aq_explicit, propname): return getattr(p, propname) raise AttributeError, propname Cheers, Evan @ digicool & 4-am
Evan Simpson wrote:
The only way (right now) to search for a property in the order PARENTS mentions them is to do so explicitly, by looping through the elements of PARENTS and checking their 'aq_explicit' for the property. Example Python snippet:
for p in REQUEST['PARENTS']: if hasattr(p.aq_explicit, propname): return getattr(p, propname) raise AttributeError, propname
I think you might be missing an else: and a couple or three tabs. ;) If I'm not wrong this should have a pretty elegant DTML equivalent: <dtml-in PARENTS> <dtml-with aq_explicit only> <dtml-if propname> <dtml-return proname> <dtml-else> <dtml-raise AttributeError><dtml-var propname></dtml-raise> </dtml-if> </dtml-with> </dtml-in> I'm not going to actually *test* it. Whether it works is left as an exercise to the reader. -- -Michel Pelletier http://www.zope.org/Members/michel/MyWiki Visit WikiCentral for the latest Zen: http://www.zope.org/Members/WikiCentral
participants (3)
-
Evan Simpson -
Michel Pelletier -
Stephen Harrison