Hanno Schlichting wrote:
> yuppie wrote:
>> That would mean that CMFDefault-the-example-application will depend on
>> z3c.form. If we are going to split off the forms we need to split off
>> all browser views and the profiles that use these views. Something like
>> 'cmf.app' that includes all the CMFDefault stuff Plone doesn't depend on.
> I'd be generally in favor of making the distinction between the
> CMFDefault-example-application and the reusable parts as used by for
> example Plone clearer.
> This can happen in two ways, though. Either move the example-application
> bits into a different package or move the reusable bits into one.
It is much easier to move views, skins and profiles around than moving
persistent or base classes to a new package.
> If you
> are really interested in doing this work, I'd be happy to figure out
> what parts of CMFDefault Plone is actually using.
Fine. I'll come back to you *if* I'll do this work. But I currently have
no plans to split off *everything* Plone doesn't use. E.g. moving
content types to a different package doesn't seem to be worth the trouble.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests