[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