[Zope-CMF] Re: method aliases

Yuppie yuppie@zedat.fu-berlin.de
Tue, 29 Jul 2003 21:35:40 +0200


Hi!


Andrew Sawyers wrote:
> I think the strangeness partially comes from when we don't want to do 
> the migration, you have to be aware of hoops to get your new types to 
> work in CMF1.4.  Adding a type with an action like: 'action':  

Just for the records: We are talking about CMF HEAD (post 1.4)

> "python:object.someMethod() + '/some_template.html'" blows up because 
> it's trying to compile the expression when you add the type to the types 
> tool - of course this returns None and blows up.  IIRC this bit of code 
> was the culprit:
> aliases = kw.get( 'aliases', _marker )
>        if aliases is _marker:
>            self._guessMethodAliases()
>        else:
>            self.setMethodAliases(aliases)
> I did not step past figuring out the work around (i.e. adding the 
> aliases dict. to my type information).

This is documented in CHANGES.txt:

"factory_type_information now has a key 'aliases' to configure Method 
Aliases in a product. This key is required, but may be empty: If it 
doesn't exist, TypeInformation will try to update by guessing aliases."

If there is a better place for that kind of information, please let me know.

> It seems like for types that don't have an aliases dict, you wouldn't 
> want to compile the action at add time....no?  I'm not sure why you'd 
> want to compile any expressions when you're adding the type; but I could 
> have overlooked something.

'(Default)' and 'view' aliases are meant to replace __call__() and view().
Compiling actions at add time works fine to find out which methods are 
called by __call__() or view() - but apparently only with CMFDefault types.

I didn't test other kinds of content types. Please send me test ftis 
that don't work right now - I'll try to fix the migration code.


Cheers,

Yuppie