restrictedTraverse doesn't give the good container
Hi, Today, I have this situation: Under my root Zope Site, I have this hierachy: - FolderA ---FolderB ----FolderC -----FolderC What is interesting is that a folder named "FolderC" appears under another folder named with the same name. Assuming the path is the good one (path=.../.../FolderB) I try : herenow = context.restrictedTraverse(path+'/FolderC') -> OK herenow = herenow.restrictedTraverse(path+'/FolderC') -> OK Now I just delete the last FolderC, I have: - FolderA ---FolderB ----FolderC I try : herenow = context.restrictedTraverse(path+'/FolderC') -> OK herenow = herenow.restrictedTraverse(path+'/FolderC') -> OK BUT here I'm just not where I think to be, just because of the acquisition !!! I have no time to have a look on this, but anyone have seen this problem and resolved it? Sincerily PS -------------------------------------------------- Oreka ! Nous sommes l'internet moins cher ! Surfez 25% moins cher avec http://www.oreka.com
On Mon, Feb 09, 2004 at 03:15:19PM +0100, Pascal Samuzeau wrote:
I try :
herenow = context.restrictedTraverse(path+'/FolderC') -> OK herenow = herenow.restrictedTraverse(path+'/FolderC') -> OK
BUT here I'm just not where I think to be, just because of the acquisition !!!
Does path start with a slash? If path is a "absolute-path reference" (i.e. it starts with a slash), and you do foo.restrictedTraverse(path), the value of foo does not matter. Therefore, context.restrictedTraverse(path+'/FolderC') and herenow.restrictedTraverse(path+'/FolderC') are exactly equivalent. This is true regardless of how many things you have named '/FolderC'. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's RETRO-<I>N</I> + 1 HAMSTER SCIENTIST! (random hero from isometric.spaceninja.com)
Pascal Samuzeau wrote at 2004-2-9 15:15 +0100:
... Now I just delete the last FolderC, I have:
- FolderA ---FolderB ----FolderC
I try :
herenow = context.restrictedTraverse(path+'/FolderC') -> OK herenow = herenow.restrictedTraverse(path+'/FolderC') -> OK
BUT here I'm just not where I think to be, just because of the acquisition !!!
I have no time to have a look on this,
Interesting that you report a problem you have no time for....
but anyone have seen this problem and resolved it?
This is normal acquisition behaviour... Modern Zope versions make "aq_inner" available to TTW code. With such versions, you can use "hasattr(obj.aq_inner.aq_explicit, XXX)" to check whether "obj" has an unaquired attribute "XXX". There is also my "hasattr_unacquired" path that provides "hasattr_unacquired". Its effect is identical to the above "aq_inner.aq_explicit" magic but it is easier to understand (for non experts)... -- Dieter
participants (3)
-
Dieter Maurer -
Pascal Samuzeau -
Paul Winkler