[Zope-dev] Overriding a method in an instance.

[Shane Hathaway]

Chris Withers wrote:
> 
> Monty Taylor wrote:
> > Make a folder that contains the overridden methods and call things
> > through the context of that folder.
> 
> Neat trick :-)
> We love acquisiton, but it won't quite do it :(
> The default index_html will get called, unless you put /folder/ on the
> end of your URL. which is horrible :(
> 
> > In the case of what it seems you want to do I'd say sub-classing is going
> > to be your real answer.
> 
> Actually, the more important case is for Trackers, where you probably
> want them to look/act differently on an instance by instance basis.
> 
> This is mainly for presentation methods, but there's no reason if it's
> solved for them, it can't be used for any other methods...

I have an idea: the _objects attribute of ObjectManagers could include
a "configurable" flag, which would tell _checkId that the object can be
overridden.

> PS: For acquisiton, is it context before containment or containment
> before cotext?

Interesting situation, that... it's always containment before context,
but standard practice in DTML figures out what initial container to use
from the context.

I just figured that last week.  To determine context, you get
obj.aq_parent.  To determine the container, you get
obj.aq_inner.aq_parent.  The strange thing about DTML methods is that
namespace attributes are essentially derived from method.aq_parent. 
method.aq_parent could be anywhere and is determined by the
second-to-last element in the URL.  But from there, acquisition
continues normally, searching via containment first and then context.

So it's mostly right-to-left, but sometimes left-to-right, and
sometimes in a less than predictable order.  I have an external method
that makes it clearer, if you're interested.

Shane