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

Reply via email to