[Zope-CMF] Re: What's the story for using Z3 content types as first-class citizens in CMF?

yuppie y.2006_ at wcm-solutions.de
Tue Feb 14 14:55:55 EST 2006

Hi Martin!

Martin Aspeli wrote:
> yuppie <y.2006_ at ...> writes:
>> The underlying question is whether we want to drop support for TTW 
>> development. I don't want that. So I prefer to keep portal types and 
>> Actions until we have a suitable Z3 replacement.
> In my own opinion, there are three levels of TTW development:
> 1. TTW Configuration (e.g. changing the user-visible name of content types,
> portal settings etc.): Critical - we really can't lose this.
> 2. TTW Template Customisation (e.g. changing the HTML of a template, or
> overriding CSS): Critical - this is one of the main reasons why Plone is
> popular, at least; people find it easy to make simple visual changes and get a
> lot of flexibility (and some ability to shoot themselves in the foot) in return.
> Telling these people to learn ZCML, make python modules, register views etc.
> will likely scare them away. Giving them tools to get what they've done TTW into
> the filesystem is nice, too.
> 3. TTW Development (i.e. create complex applications TTW, including the type of
> python logic that can't easily be put in a page template python: statement, even
> though you know better): Perhaps unnecessary to support. When you want to build
> "real" applications, TTW will likely be too limiting anyway. Having ways of
> making "proper" views and utilities TTW seems like unnecessarily difficult to
> write, when most people who do this will want to do it on the filesystem anyway.

I would differentiate further: The next level after template 
customization is presentation layer customization. This is currently 
possible. Making methods of the view class overrideable by scripts 
should not be much harder than making the view template overrideable.

> Those are my opinions anyway, based on what I see people, especially newbies, in
> the Plone world do.

Use cases for presentation layer customization I have in mind:

- rapid prototyping

- site specific customizations

- hosting scenarios where you don't have filesystem access

>> But nevertheless I'd like to use Z3 content types instead of CMF 
>> *content* types. And therefor we should agree on 90% of what has to done.
> I completely agree - this is the big win. However, one of the things I'd really
> like to gain from Z3 content types is add forms! That does imply a certain
> degree of interoperability with Z3 menus, at the very least.

Yes. I also like to use add forms. But primarily this implies 
refactoring the content creation machinery.

> Perhaps, as Florent suggested, the migration path is to let the relevant APIs
> return both ZODB FTIs and "fake" FTIs for ZCML-registered content types, and to
> let the action tools return Z3 menu-defined actions as well as ZODB-persisted
> ones. Then we may decide to ultimately drop the old way if the new way covers
> all the bases, or we may let them co-exist for some time.

Well. There are some drawbacks:

- ZCML-registered portal types are global, not site specific

- there is no longer a mechanism to make sure TypeInfo IDs are unique

- these TypeInfo objects are not customizable TTW

- adding an additional way to create TypeInfo objects makes things more 
complex: you have to maintain some portal type and Action settings in 
GenericSetup profiles and others in ZCML



More information about the Zope-CMF mailing list