[Zope-CMF] Re: modifying TypeInformation's properties

Florent Guillaume fg at nuxeo.com
Thu Sep 2 14:22:04 EDT 2004


>> Anyone opposed to allowing TypeInformation's properties to by added ?
>
> I did not think enough about it to be opposed to it, but I'm 
> concerned. An "everything goes" solution doesn't just add new 
> possibilities, it also adds much more complexity.

Why complexity ? It's just new metainformation about the type that 
other code will ignore.

>> It's a pain to monkey-patch everything when I could do a simple 
>> manage_addProperty. And I see nowhere the rationale for disallowing 
>> this. The culprit is TypeInformation's base class 
>> SimpleItemWithPropertie whose manage_propertiesForm disables schema 
>> edition.
>
> Could you please specify some use cases for adding properties? Are 
> there any use cases where different properties per TypeInformation 
> object are needed? Would a small add on product define its own 
> properties or would there be a standardized schema for CPS or Plone?

Standard use case: flagging certain types for certain kind of 
operations in the portal. For instance I want to only display certain 
content types in some menus (like in advanced search: 
cps_is_searchable). Or I want to add some types (portlets) in some 
menus. Or I want to flag some types as being displayed in the 
"folderish" parts of a folder listing, and others as "documentish" 
(cps_display_as_document_in_listing, to have a  view that presents 
folders at top then documents).

For all these, the natural place to add information is on the TI object 
itself.

> Why do you have to monkey-patch TypeInformation? Can't you subclass 
> FTI / STI?

I'm adding these informations on any kind of TI.

> Note that CMFSetup expects the default schema. Don't know if it just 
> ignores additional properties.

Good point, I'll check what it does.

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:fg at nuxeo.com



More information about the Zope-CMF mailing list