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

[Alec Mitchell]

On 2/11/06, Martin Aspeli <optilude at gmx.net> wrote:
> On Sat, 11 Feb 2006 10:04:39 -0000, Jens Vagelpohl
> <jens-G0EXMjp3EnnNLxjTenLetw at public.gmane.org> wrote:
>
> > There is no such code right now and AFAIK no one has even looked at it.
> > If anyone wants to take this up and the proposal/code is accepted the
> > earliest target would be CMF 2.1.
> >
> > I'm not sure how much work is needed for it. It's a matter of
> > experimenting to see how far you can get before hitting walls I suppose.
>
> Cc'ing in Alec - I'm sure he has experiences to share from creating and
> using plone_schemas.
>
> Alec - you have indicated that you may be interested in working on
> plone_schemas more. Perhaps that work should sit at the CMF level?

Yes, some of what's there (bugfixes for the add and edit views mostly)
needs to be pushed into Five, The views themselves should perhaps be
pushed into CMF, and only a couple small bits would be expected to
remain plone specific (auto-renaming, some ui stuff for the field
display).  One thing that we really need on the CMF level is a wayto
integrate z3 AddForms (via the addMenuItem declaration) into the CMF
add menu, once that is done the FTI will largely be unnecessary (FTI
is largely about creating content using a means which is obsoleted by
z3 add forms).  I would think that to the extent that an FTI remains
necessary, it can be provided with a GenericSetup xml profile (some of
the types I use in listen, which uses plone_schemas, do not have an
FTI at all).  At the moment plone_schemas is quite limited because it
is designed to work with zope 2.8, which at this point is a bit
crippling in terms of doing z3 stuff properly.

> > As a general idea it does sound interesting because it is right on the
> > roadmap towards combining CMF and Zope 3 in order to make CMF a thinner
> > and thinner layer on top of Zope 3 technologies.
>
> In the context of Plone, it's also attractive because it may provide us
> with a lighter and better integrated alternative to Archetypes, which in
> itself has replaced plain-CMF content type coding in the Plone world
> almost completely. So it's not only about convergence, it's about making a
> fairly fundamental task easier and making it sit at a more appropriate
> level in the stack.

+1

Alec