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 - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests