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
> 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.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -