[Zope] context in a Product's python code (not Python Script)

[John Hohm]

On Wed, Dec 04, 2002 at 10:21:03PM +0100, Dieter Maurer wrote:
> John K. Hohm writes:
>  > Quoting Dieter Maurer <dieter@handshake.de>:
>  > > John K. Hohm writes:
>  > > > I have a Page Template and Python Script that are working fairly well
>  > > > together to generate a navigational menu on my site, and now I want to
>  > > > make them part of a product.  I have tried this:
>  > > 
>  > > The "context" equivalent in a Python product's method
>  > > is usually "self.aq_parent"; the "container" equivalent
>  > > "self.aq_inner.aq_parent".
>  > 
>  > I expected you to be right, so I tried a simple method like this:
>  > 
>  >     security.declarePublic('foo')
>  >     def foo(self):
>  >         """Test method"""
>  >         return self.aq_parent.absolute_url()
>  > 
>  > When called through the web, it displays the URL for the parent of the instance
>  > that defines foo, not the object on which I'm calling the method.  Aargh!
> You are right and I need to be more careful!
> 
>   Accessing a method can restrict acquisition information.
> 
>   The precise rules are difficult to grasp, but it is easy
>   to present a case where you are unable to obtain the true context:
> 
>     An acquisition wrapper has two components "self" and "parent".
>     When you look up an attribute (such as a method) it is
>     first looked up in "self" and, if this lookup fails,
>     it is looked up in "parent".
> 
>     When the lookup in "self" fails, the method's "self"
>     will not have the full acquisition
>     context and ".aq_parent" will not give
>     to true context.
>     Otherwise, it might but need not be the case.

You seem to be saying that luck is required for a method to get proper
acquisition information.  How can this be?  Aren't methods acquired all over
the place?  What alternatives to methods exist for defining objects that can
be acquired?