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

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  -

See for bug reports and feature requests

Reply via email to