Advertising

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