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

[Tres Seaver]

Florent Guillaume wrote:
>>>>In general, I'd like to see a discussion about questions like these:
>>>>
>>>>- Do we need more or less configuration options in the type info 
>>>>objects? See <http://collector.zope.org/CMF/33> for a proposal to remove 
>>>>"allow discussion" configuration from type infos.
>>>
>>>
>>>#33 specifically talks about UI, not where the info is stored.
>>>I'm not aware of anyone apart from you advocating moving that info
>>>somewhere else from the TI.
>>
>>I'm not advocating anything. I'm just asking questions.
>>
>>The checked in change adds an UI for configuring arbitrary properties. 
>>That's contrary to the goals of <http://collector.zope.org/CMF/33>.
> 
> 
> We'd want Tres's opinion on that. Tres, could you expand a bit on what
> exactly you mean by #33 ? I see it only as a discussion-specific UI
> problem. To me the information still should be stored in the TI, and
> available in its list of properties.

I think there are two forces in play here:

   - We would like type informatino objects to have a fairly simple
     contract / set of responsibilities, in order to make them more
     robust.

   - We have use cases for storing additional type-specific metadata
     (the discussability flag, for instance).

Given that TIs already support the ZMI Properties tab, we could 
proabably address both goals by removing "special" properties (like the 
discussability flag), but allowing arbitrary "add-on" properties, set by 
the setup tool / site constructors, etc.  The discussions tool could 
then either store the discussability flags for each type in itself, or 
could use an "add-on" property on the TI.

>>If products use additional properties, other products have to care about 
>>providing them.

Nope, not if they are "optional";  only the code which sets up the site 
should care about them.  If we add an extensible mechanism for creating 
extra properties to CMFSetup, then all the policy moves to the CMFSetup 
profile, where it belogs.

>>So if you write a content type, you have to add properties like
>>
>>   cps_display_as_document_in_listing
>>   cps_is_searchable
>>   cps_this
>>   cps_that
>>   plone_is_folderish
>>   plone_is_searchable
>>   plone_that
>>   cmf_default_this
>>
>>That bloats the 'Properties' tab.
> 
> Well that tab is only important for CMF developers or site configurators
> anyway, and it centralizes information. I hardly see it as bloat.

Another option would be to have the extra properties stored in a 
separate propertysheet, which could be added to the TI in the site 
setup.  Such "extra" propertysheets would not "pollute" the properties 
tab, which wouldn't display them at all.  The extra propertysheets would 
take on the role that annotations play in Zope3.

>>Adding new properties TTW is error prone: You might type names wrong;
>>nothing helps you to keep the TI objects in sync; ...
> 
> 
> Of course and in 99% of cases an installer would do it.
> 
> 
>>All the known issues with the Properties machinery. I believe there was 
>>a good reason why the SimpleItemWithProperties class was added to CMF.

AFAIK, that class has been there since revision 1.1 of CMFCore.utils, 
and has been a base for TypeInformation since revision 1.1 of 
CMFCore.TypeInformation.  I don't recall the rationale at this point for 
  restricting the schema.

> For me SimpleItemWithProperties is nice when you *know* you don't want
> to change the schema properties. IMHO that's not the case for
> TypeInformation.

Maybe we should explore the "alternate propertysheets" notion?

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com