getPhysicalPath returns the physical path to an object ignoring how I got there through Acquistion. There are a bunch of variables in the REQUEST that tell me how I got to an object, but we have an object that is messing around with traversal, so the REQUEST variables arent ideal. Is there a simple method like getAcquistionPath() that tells me how I was required without having to do some sub optimal REQUEST variable hacking / string matching? Thanks. -- Andy McKay.
Should be "how I was acquired" not required. Duh. -- Andy McKay. ----- Original Message ----- From: "Andy McKay" <andym@ActiveState.com> To: <zope-dev@zope.org> Sent: Thursday, March 15, 2001 6:26 PM Subject: [Zope-dev] getPhysicalPath?
getPhysicalPath returns the physical path to an object ignoring how I got there through Acquistion. There are a bunch of variables in the REQUEST that tell me how I got to an object, but we have an object that is messing around with traversal, so the REQUEST variables arent ideal.
Is there a simple method like getAcquistionPath() that tells me how I was required without having to do some sub optimal REQUEST variable hacking / string matching?
Thanks.
-- Andy McKay.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Is there a simple method like getAcquistionPath() that tells me how I was required without having to do some sub optimal REQUEST variable hacking / string matching?
I don't know of any (but that doesn't mean there isn't one). But couldn't you walk up the aq_parent? -- Tom Jenkins devIS - Development Infostructure http://www.devis.com
Is there a simple method like getAcquistionPath() that tells me how I was required without having to do some sub optimal REQUEST variable hacking / string matching?
I don't know of any (but that doesn't mean there isn't one). But couldn't you walk up the aq_parent?
Acquisition tip-o-the-day: you can use: print object.aq_chain The aq_chain attribute (computed at time of access) provides a list (in reverse order) of the objects in the acquisition path. Hope this helps! Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
Ahh... thanks Brian. Thats a new one to me :)
The aq_chain attribute (computed at time of access) provides a list (in reverse order) of the objects in the acquisition path.
Hope this helps!
Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Hi!
Ahh... thanks Brian. Thats a new one to me :)
To me, aswell. Is this documented somewhere? ;-) And can someone explain to us where the differences between aq_chain and getPhysicalPath() are? Actually getPhysicalPath() seems also to walk up aq_parent. Or am I missing something? regards, Christian
The aq_chain attribute (computed at time of access) provides a list (in reverse order) of the objects in the acquisition path.
Hope this helps!
Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
-- COM.lounge http://comlounge.net/ communication & design info@comlounge.net
From: "Christian Scholz" <cs@comlounge.net>
And can someone explain to us where the differences between aq_chain and getPhysicalPath() are? Actually getPhysicalPath() seems also to walk up aq_parent. Or am I missing something?
"aq_chain" gives you a list of the objects traversed to get to your object, in reverse order. "getPhysicalPath" gives you a tuple of the Ids of all objects on the shortest path from the root to your object. So, given a hierarchy like this: A__B__C |_D |_E Object C has physical path ('', 'A', 'B', 'C') no matter how you get to it. Its acquisition chain, on the other hand, depends completely on the path you use to access it: A/B/C => [C, B, A] A/D/B/C => [C, B, D, A] A/B/D/E/C => [C, E, D, B, A] *WARNING*: "aq_chain" does *not* tell you the order in which acquisition will search the objects. That is more complicated. Cheers, Evan @ digicool
To me, aswell. Is this documented somewhere? ;-)
It's not in the Acquisition.stx in the ExtensionClass docs - probably they were never updated when it was added. I think that aq_chain is most useful as a debugging aid rather than something one would use in an application (which is not to say that it shouldn't be documented). It would be a good idea to add this to the Collector as a documentation issue.
And can someone explain to us where the differences between aq_chain and getPhysicalPath() are? Actually getPhysicalPath() seems also to walk up aq_parent. Or am I missing something?
The sequence returned by aq_chain is the actual chain of 'acquisition contexts', or the 'access path' rather than the actual containment path. For example, given the object hierarchy: app FolderA index_html FolderB If you say: ob = app.FolderA.FolderB.FolderA.index_html then the aq_chain will be: [index_html, FolderA, FolderB, FolderA, app] This list is created by basically taking the 'aq_parent' of each object from 'ob' on up until there are no more aq_parents. The actual *containment* path is different; in our example the containment path would be: [index_html, FolderA, app] To derive the containment path, instead of just walking up the aq_parents you have to take the aq_inner (to get the innermost wrapping of the object) for each object and then take the aq_parent of that. For example (not tested, but should work): def containment_chain(object): # return a list similar to aq_chain, but consisting # only of the actual containment path. result = [] result.append(object) while hasattr(object, 'aq_inner'): innermost_wrapping = object.aq_inner true_parent = innermost_wrapping.aq_parent result.append(true_parent) object = true_parent return result Hope this helps! Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
On Fri, 16 Mar 2001, Brian Lloyd wrote:
To me, aswell. Is this documented somewhere? ;-)
It's not in the Acquisition.stx in the ExtensionClass docs - probably they were never updated when it was added. I think that aq_chain is most useful as a debugging aid rather than something one would use in an application (which is not to say that it shouldn't be documented). It would be a good idea to add this to the Collector as a documentation issue.
A better place would be the sourceforge issue tracker for the dev guide: http://sourceforge.net/projects/zope-devel -Michel
Brian Lloyd wrote:
Is there a simple method like getAcquistionPath() that tells me how I was required without having to do some sub optimal REQUEST variable hacking / string matching?
I don't know of any (but that doesn't mean there isn't one). But couldn't you walk up the aq_parent?
Acquisition tip-o-the-day: you can use:
print object.aq_chain
The aq_chain attribute (computed at time of access) provides a list (in reverse order) of the objects in the acquisition path.
Is this *cough* documented anywhere? grep -r on the Zope source comes up with (not counting test_AqAlg.py): ./lib/Components/ExtensionClass/src/Acquisition.c:module_aq_chain(PyObject *ignored, PyObject *args) ./lib/Components/ExtensionClass/src/Acquisition.c: {"aq_chain", (PyCFunction)module_aq_chain, METH_VARARGS, ./lib/Components/ExtensionClass/src/Acquisition.c: "aq_chain(ob [, containment]) -- " So nobody (including the various Products I have installed) uses this incredibly useful attribute. I have numerous places in my source where I loop through aq_parent attributes. It'd be nice to have even a mention in the acquisition documentation. Poking around the Acquisition C source tells me that there's another attribute, aq_inner, that isn't documented either. Richard -- Richard Jones richard@bizarsoftware.com.au Senior Software Developer, Bizar Software (www.bizarsoftware.com.au)
<snip, regarding aq_chain>
So nobody (including the various Products I have installed) uses this incredibly useful attribute. I have numerous places in my source where I loop through aq_parent attributes.
A good question is whether aq_chain really should be a public interface. It was added (I think) as a debugging aid rather than necessarily to be used by application code. This is probably one for Jim to answer (I've CC'ed him on this). If Jim thinks it should be part of the public interface, then someone should add a documentation bug report on this so that Amos and Michel can see that it is included in the right places.
It'd be nice to have even a mention in the acquisition documentation. Poking around the Acquisition C source tells me that there's another attribute, aq_inner, that isn't documented either.
I think aq_inner is a public interface - this should also be a doc bug report. Before anyone asks, note that 'aq_uncle' is _not_ part of the public interface, and is only an exercise in Jim having fun :^) Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
Brian Lloyd wrote:
<snip, regarding aq_chain>
So nobody (including the various Products I have installed) uses this incredibly useful attribute. I have numerous places in my source where I loop through aq_parent attributes.
A good question is whether aq_chain really should be a public interface.
Yes.
It was added (I think) as a debugging aid rather than necessarily to be used by application code. This is probably one for Jim to answer (I've CC'ed him on this).
Done. ;)
If Jim thinks it should be part of the public interface, then someone should add a documentation bug report on this so that Amos and Michel can see that it is included in the right places.
Well, it is documented, along with other module goodies in the Interfaces Wiki: http://www.zope.org/Members/michel/Projects/Interfaces/AcquisitionModuleInte...
It'd be nice to have even a mention in the acquisition documentation. Poking around the Acquisition C source tells me that there's another attribute, aq_inner, that isn't documented either.
It's documented in the Wiki too.
I think aq_inner is a public interface - this should also be a doc bug report.
Before anyone asks, note that 'aq_uncle' is _not_ part of the public interface, and is only an exercise in Jim having fun :^)
And Bob's your uncle. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org
participants (9)
-
Andy -
Andy McKay -
Brian Lloyd -
cs＠comlounge.net -
Evan Simpson -
Jim Fulton -
Michel Pelletier -
richard＠bizarsoftware.com.au -
Tom Jenkins