On 03 Jul 2002 18:21:36 -0400
Tres Seaver <tseaver@zope.com> wrote:
> On Wed, 2002-07-03 at 16:59, J C Lawrence wrote:
>> I then register the skins etc in the normal way, which seems to work.
>> The problem is that the methods bound to new instances of the class
>> are the old topic_* methods (eg topic_view) rather than my new
>> caltopic_* methods (eg caltopic_view).
> It sounds like your objects don't know that they should be of type
> 'CalTopic'; their 'portal_type' attribute is likely set to 'Topic', or
> empty (in which case they fall back to the 'meta_type' of their
> class).
That makes sense.
> Are you creating these objects using some mechanism other than
> 'invokeFactory' on their folder? If so, you need to arrange for them
> to have '_setPortalTypeName( "CalTopic" )' called on them after they
> are constructed.
Urrk. I'm not sure. How would I know/determine/do that?
My product currently consists of an almost verbatim copy of CMFTopic's
__init__.py, slightly touched over to descend from CMFTopic etc; a
touched over copy of Topic.py (renamed to CalTopic.py) with the
factory_type_information rewritten as shown previously and the
queryCatalog method rewritten to do what I want; and a set of custom
skins based off CMFTopic's.
I haven't traced exactly how instances are created. The apparency is
that an inherited factory method picks up the factory member of
factory_type_information which points to:
def addCalTopic( self, id, title='', REQUEST=None ):
"""
Create an empty caltopic.
"""
caltopic = CalTopic( id )
caltopic.id = id
caltopic.title = title
self._setObject( id, caltopic )
if REQUEST is not None:
REQUEST['RESPONSE'].redirect( 'manage_main' )
Which is an almost verbatim ripoff of CMFTopic's.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw@kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.