Tres Seaver wrote:
[...] I think that this split ("framework" in GenericSetup, CMF-specific policy in CMFSetup) might make the overall approach used in CMFSetup more widely useful. I can see that making CMF dependent on a non-core package would be tricky; can anyone point out other issues, or suggest workarounds?
There are other CMF features that are also distributed as standalone products. FileSystemSite and CookieCrumbler come to my mind. Maybe all these products should live in the CMF repository and CMF should depend on them instead of duplicating code?
Recently, I also thought about splitting of a generic part from CMFSetup. Trying to write handlers for portal_catalog I found that at least 90% of the work has nothing to do with the CMF and handlers for generic Zope objects like ZCatalog and indexes would be better located in the Zope core.
BTW, I did add a new feature (import from tarballs) to GenericSetup; if the CMF community can't see a way to use GenericSetup, I will look at porting that feature back to CMFSetup (it shouldn't be too hard).
Great. How ever the dependencies are resolved - this should become part of the CMF.
Cheers, Yuppie _______________________________________________ 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