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