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

[Julien Anguenot]

Hi,

The problem for us is that we need to monkey patch all the time just to
add a new property.

Something like that :

from Products.CMFCore.TypesTool import TypeInformation as FTI

if 'cps_is_portlet' not in [prop['id'] for prop in FTI._properties]:
     FTI._properties = FTI._properties + (
         {'id':'cps_is_portlet', 'type': 'boolean', 'mode':'w',
          'label':'CPS Portlet'},
         )
     FTI.cps_is_portlet = 0

It wouldn't cost anything being able to extend the properties through a
dedicated API. It doesn't add complexity at all, does it ?

We don't wanna create one TypeInformation just for that neither.

I don't know much yet about CMFSetup and the possible issue though.

Regards,

	J.

yuppie wrote:
> Hi!
> 
> 
> Florent Guillaume wrote:
> 
>>> Maybe special kinds of types should have their own Type Information 
>>> class?
>>
>>
>> Why ? The TypeInformation classes are implementation details about the
>> type. The should not constrain how the TI is used, and should be
>> interchangeable.
>>
>>> Factory-based Type Information and Scriptable Type Information are 
>>> made for ordinary content types.
>>
>>
>> I don't know what you mean by that. They are made to construct CMF types.
> 
> 
> CMF *content* types. If I understand the concept of portlets right, they 
> are *presentation* objects. Sometimes its useful to use different 
> classes for different kinds of objects. Don't know if that's the best 
> solution in this case.
> 
>>> 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>.
> 
>>> - Is the current default schema up to date, or should some fields be 
>>> added / modified?
>>>
>>> - If we allow to add arbitrary fields to FTIs and STIs, how do 
>>> components play together? Are the content types responsible for 
>>> setting these values or the components that use these fields?
>>
>>
>>
>> Just see them as annotations. Those who care about them will set them
>> and check them.
> 
> 
> If products use additional properties, other products have to care about 
> providing them.
> 
> 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. Adding new properties TTW is error 
> prone: You might type names wrong; nothing helps you to keep the TI 
> objects in sync; ...
> 
> All the known issues with the Properties machinery. I believe there was 
> a good reason why the SimpleItemWithProperties class was added to CMF.
> 
> 
> Cheers,
>     Yuppie
> 
> 
> _______________________________________________
> Zope-CMF maillist  -  Zope-CMF at lists.zope.org
> http://mail.zope.org/mailman/listinfo/zope-cmf	
> 
> See http://collector.zope.org/CMF for bug reports and feature requests
> 

-- 
Julien Anguenot | Nuxeo (Paris, France)
mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66