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?