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: > Hi! > > > 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 > >>DefaultDublinCoreImpl. > > > > 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. > > > Cheers, > > Yuppie > > -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests