[Zope-CMF] Re: method aliases

[Yuppie]

Hi!


Chris McDonough wrote:
> What is the purpose of the machinery for "method aliases" in the current
> CMF core types tool?  Can anyone give a 10-word summary? 

This is a result of the type action changes from CMF 1.3 to 1.4. Type 
actions are now absolute URLs, surrounded by other attributes useful for 
UI representation.

The problem in CMF 1.4 is: _getViewFor and getActionById restrict the 
usage of type actions and need some strange code. I quote Florent:

>  - because _getViewFor and getActionById are used to find a method, they
>    have to extract it from the above URL using a hack (passing a
>    context-less expression-context, with an empty object_url and then
>    stripping resulting the initial slash).

The old machinary still works, but I hope __call__() methods using 
_getViewFor() and view() methods can be removed in the long run.

getActionById() can be replaced by using an alias like 'edit_form' for 
all types.

As a side effect, it's now easy to set aliases like 'index.html'.

> The _guessMethodAliases method in CMFCore TypeInformation attempts to
> evaluate FTI action expressions in the context of the types tool, which
> really doesn't work for many actions.  For instance, there may be
> objects which expect to reliably have a parent object of a certain kind;
> their actions depend on the object having this context.
> 
> The upshot of this magic is that you can't create content types for
> objects that can't have a factory type information which includes
> actions that don't work at type creation time, although they would work
> fine during normal operation.
> 
> The workaround is to specify an empty dict as the 'alias' of an fti, but
> why is this necessary?

Well...

1.) I'd like to have a migration path. If _getViewFor() and view() will 
be deprecated in a future version, type infos need to have '(Default)' 
and 'view' aliases.

2.) The 'on the fly' migration magic is what was used to migrate from 
CMF 1.3 to 1.4. It caused a lot of trouble, but I hope 
_guessMethodAliases does a better job. AFAICS it works well with all 
content types distributed with CMF. If there is a chance to improve 
_guessMethodAliases, I'll do the necessary work.

3.) To do migration 'on the fly', we need a criterion to find out if 
migration is necessary. Right now this criterion is the existence of the 
'aliases' dict. An other posibility would be to introduce something like 
a version number for ftis.


Any ideas to improve this are welcome.


Cheers,

Yuppie