Chris Withers <[EMAIL PROTECTED]> writes:

> Martin Aspeli wrote:
> > Alec Mitchell's plone_schemas product lets you use such types in Plone, 
> > though he derives from CMF's PortalContent (as I recall) and manually 
> > constructs an FTI.
> FWIW, I think this is an exceptionally bad idea.
> I'd much prefer to see CMF grow a way to use Z3 content types without 
> having to drag them down into the mire that is portal_types and the 
> actions system :-S
> Maybe some kind of parallel thing where the UI-level stuff amalgamates 
> both the CMF and Z3 ways of doing things (portal_types/content types and 
> actions/menus) with the aim being eventually to drop the old CMF stuff?

Which was sort of the point of my post, if you recall... to make Z3 contet types
first-class citizens in a CMF world. Now, there are some abstract things that
CMF may want to incorporate as interfaces, such as abstract metdata about a type
(display name, actions, aliases), catalog awareness (via events) etc. I imagine
these should be described as interfaces and/or ZCML statements, at which point
we can start to use adapters to make Z3 content types work in a CMF context.

So far, I guess, the discussion has shown that we need:

 - An abstracted, events-driven alternative to CMFCatalogAware

 - An alternative to the portal_types/FTI mechanism that works in ZCML and/or
through some generic interface with appropriate adapters

 - A way of getting ZCML-defined browser menus such as the add menu into CMF's
add menu, and probably have similar mechanisms for actions in various 

Of couse, as Alec points out, you need a whole bunch of other Zope 2 stuff as
well, such as RoleManager etc. Perhaps having a content type that derives from
ProtalType in a CMF world isn't so much worse than having one derive from
Persistent in a pure Z3 world; you simply have to keep writing to interfaces and
use adapters for additional logic and functionality.


Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to