How to handle unknown meta_type in GS

erstellt von pgerken — zuletzt geändert: 2013-05-15T10:21:27+02:00
Comments
We were lost when supporting multiple Plone versions with generic setup and the typeinfo step. Soon there won't be the Topic type any more. Removing declarations for the Topic type and leaving users of old Plone-Versions behind is no option. We found a way to handle it in a single profile.

Our package collective.noticeboard should work with somewhat older Plone sites and new and shiny ones that ditch AT in favor of using DX all the way down.

Therefore we must declare an available view for Topics even though Topics might not exist in the targeted Plone sites.

Trying to import our profile in such a case results in a traceback like that:

Module Products.GenericSetup.utils, line 509, in _importBody
Module Products.CMFCore.exportimport.typeinfo, line 210, in _importNode
Module Products.GenericSetup.utils, line 570, in _initObjects
- __traceback_info__: ('Topic', '')
ValueError: unknown meta_type ''

We don't want to create confusion by adding multiple profiles and we don't want to enable different profiles in zcml based on import statements, because if you have a Topic or not is decided during runtime.

Fortunately there is an undocumented feature hidden in GS: You can declare your type declaration as deprecated. This way, GS does not try to initialize the object and does not try to create the type information object if it does not exist.

Be careful about this directive, this works for the typeinfo step, you have to test, if it does not miss important actions when used in other steps.

This is our new types.xml:

<?xml version="1.0"?>
<object name="portal_types"
        meta_type="Plone Types Tool">

    <object name="Folder"/>
    <object name="Topic" deprecated="True"/>
    <object name="Collection"/>
    <object name="Plone Site"/>

</object>
Kommentare unterstützt durch Disqus