OK, so, interfaces, and a new base-class (which really isn't a
five-class anyway) should go into CMF, then? The typeinfo (if it even
is the right way to do this at all) and the menu-action mapping stays
in CMFonFive? That makes sense to me.
On 5/25/05, yuppie <[EMAIL PROTECTED]> wrote:
> Lennart Regebro wrote:
> > On 5/24/05, yuppie <[EMAIL PROTECTED]> wrote:
> >>There is already the CMFonFive project, but now that Zope 2.8 ships with
> >>Five I'd like to see basic Five support in CMF itself:
> > Well.... you have a point. I see some options:
> > 1. Moving CMFonFive to Zope corps CVS and simply shipping it with the
> > next version of CMF.
> > 2. Moving the things that are in CMFonFive into CMFCore.
> Moving CMFonFive to the CMF repository might make sense. But I don't
> think it is mature enough to be shipped with the CMF distribution or to
> be integrated into CMFCore.
> And while CMF interface definitions really don't belong into an add-on
> product, there is nothing wrong with shipping additional tools and
> TypeInfo classes in separate products.
> > 3. Moving just some parts, and thereby still requireing CMFonFive for
> > any reasonably CMF integration, and hence gaining very little. ;)
> Maybe we first have to discuss what we want to gain with Five support.
> My goal is to use Five technology for features CMF doesn't provide or
> that could be significantly improved by using Five. I'm sure there are
> other areas where CMF could benefit from Five, but these are the things
> I've currently on my list:
> - schema based content and forms:
> There are still some issues that have to be resolved in Five, but the
> CMF changes I proposed are all I need in CMF.
> - object specific behavior based on marker interfaces:
> Flon does it in a Plone specific way. I think this could become a
> generic Five feature, but I still have to figure out why Zope 3.1 has
> lost the UI for marker interfaces.
> - events:
> Didn't work on this so far, but it would be really nice if we could use
> Five events in CMF.
> >>3.) a base class for Five content:
> >>The PortalContent class does not implement everything required in
> >>CMFDefault. AFAICS at least some DublinCore methods are missing. We
> >>could either add a subset as in PortalFolder or use the complete
> > Well, that's still not a Five issue. But it could be a reasonably
> > thing to have in CMFDefault anyway.
> I agree that the class as proposed would be useful for non-Five content
> as well. But there might be reasons to make that base class Five
> specific at a later point, so I thought it would be a good idea to
> announce it as five specific from the beginning.
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests