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
