[Zope-CMF] [dev] CMF 2.2 plans?

[Charlie Clark]

Am 02.03.2009 um 19:27 schrieb yuppie:

>>> This is on my todo list, but I still have to write a proposal.
>>
>> Hmm, I don't recall the issue here.
>
> There wasn't much discussion about this.
>
> Some time ago Dieter asked for grouping support:
> http://mail.zope.org/pipermail/zope-cmf/2008-September/027776.html

I'm still struggling with the abolition of TypeInfo actions so I'd  
appreciate more discussion or simply explanation of this.

>>> Or we could
>>> move the forms and other views to a separate package. That way
>>> CMFDefault would not depend on zope.formlib nor on z3c.form.
>>
>> I would favor the latter.  cmf.forms, maybe?
>
> Don't know. I don't think we have the resources to maintain several
> kinds of full skins for CMFDefault. The browser views should *replace*
> the old skins and z3c.form is quite useful for writing all the  
> necessary
> forms.

I agree on both those points. In fact I'd rather reorder CMFDefault to  
use packages for each content type with their own dedicated browser  
folder and views and the same for the tools. For me the only thing is  
whether CMFDefault/formlib is in the right place. Tres, is this what  
you're referring to with by cmf.form(lib)? This itself will depend on  
whichever library we're using - which I think will be z3c.forms post  
CMF 2.2

> That would mean that CMFDefault-the-example-application will depend on
> z3c.form. If we are going to split off the forms we need to split off
> all browser views and the profiles that use these views. Something  
> like
> 'cmf.app' that includes all the CMFDefault stuff Plone doesn't  
> depend on.


I'm not sure if that is a win. Moving to views should, at some point,  
allow us to deprecate non-view object rendering. But maybe that is a  
separate point?

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226