[Zope-CMF] Re: Adding a customized FTI class to CMF (1.4 + 1.5)

[yuppie]

Hi Christian!


Christian Heimes wrote:
> We've some use cases which require to have an enhanced version of 
> CMFCore.TypesTool.FactoryTypeInformation. This includes 
> additional/enhanced security checks and additional data in the FTI. See 
> http://thread.gmane.org/gmane.comp.web.zope.plone.archetypes.devel/4177

(I'm sure you know that contributions to the CMF are always welcome if 
they address a general CMF issue, so there seems to be a good reason to 
resolve these issues in Archetypes...)

> How to register a new FTI class? In CMF 1.4 there is a typeClasses dict 
> in the TypesTool module. In CMF 1.5 the dict was removed some days ago.

Only HEAD (CMF 1.6), CMF 1.5 still has the typeClasses dict.

They are now registered like any other class in Zope. This is how 
FactoryTypeInformation is registered:

     context.registerClass(
         TypesTool.FactoryTypeInformation,
         permission=ManagePortal,
         constructors=( TypesTool.manage_addFactoryTIForm, ),
         icon='images/typeinfo.gif',
         visibility=None)

"visibility=None" and the fact the class implements ITypeInformation 
(=interfaces.portal_types.ContentTypeInformation) make it only available 
inside the types tool.

> How to make sure the new FTI class can be stored by CMFSetup?

The setup handlers in typeinfo.py are responsible for TypeInfos, but 
they just work with default FTIs/STIs. So you have to write customized 
handlers and ship them with your product. And a profile that uses these 
handlers.


At least unless someone improves the default handlers:

I'll soon check in a new Action machinery that allows to plug in custom 
Action classes. This machinery comes with setup handlers that should 
work with most custom Action classes out of the box. We could write 
similar default setup handlers for TypeInfos, making custom handlers 
unnecessary.


Cheers,

	Yuppie