[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