Overriding a method in an instance.
Hi, I guess this should be a feature request for the collector but I thought I'd see what other people thought first... I'd really like to be able to override methods in an instance of an object. Examples I can think of are Squishdot and the Tracker. In Squishdot, or any ZCatalog for that matter, it'd be great to override searchResults to return what I want, formatted how I want. In Tracker, the same could be said for index_html. These may be bad examples, but hopefully you see what I mean... Anyway, if you do try to override, you get a 'This id is already in use' error. How do you get around it and how should this problem be solved? cheers, Chris
It seems to me that the problem here is in appearance. Although it seems that you're aquiring an index_html or searchResults in those cases, they are actually instantiated in scope just like anything else you'd add inside that particular object, you just can't see them. So you have two choices. Sub-class Tracker or Squishdot and override that way. OR Make a folder that contains the overridden methods and call things through the context of that folder. In the case of what it seems you want to do I'd say sub-classing is going to be your real answer. Hope that helps... Monty
>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 7/10/00, 4:11:08 PM, Chris Withers <chrisw@nipltd.com> wrote regarding [Zope-dev] Overriding a method in an instance.:
Hi,
I guess this should be a feature request for the collector but I thought I'd see what other people thought first...
I'd really like to be able to override methods in an instance of an object. Examples I can think of are Squishdot and the Tracker.
In Squishdot, or any ZCatalog for that matter, it'd be great to override searchResults to return what I want, formatted how I want.
In Tracker, the same could be said for index_html.
These may be bad examples, but hopefully you see what I mean...
Anyway, if you do try to override, you get a 'This id is already in use' error. How do you get around it and how should this problem be solved?
cheers,
Chris
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
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 imagine it'd need playing with python name spaces and/or acquisition to implement, but might well be worth it. cheers, Chris PS: For acquisiton, is it context before containment or containment before cotext?
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
Shane Hathaway wrote:
I have an idea: the _objects attribute of ObjectManagers could include a "configurable" flag, which would tell _checkId that the object can be overridden.
Shane, Is this what became the ConfigurableInstances thing at: http://www.zope.org/Members/hathawsh/ConfigurableInstances/ ? Or is that something different that solved the same problem? cheers, Chris
Chris Withers wrote:
Shane Hathaway wrote:
I have an idea: the _objects attribute of ObjectManagers could include a "configurable" flag, which would tell _checkId that the object can be overridden.
Shane,
Is this what became the ConfigurableInstances thing at: http://www.zope.org/Members/hathawsh/ConfigurableInstances/ ?
Yes, for now. We need to start a Wiki on dev.zope.org about this. Shane
participants (3)
-
Chris Withers -
Monty Taylor -
Shane Hathaway