Hanno Schlichting wrote:
zope.file
I think this package is just misnamed and should have been zope.app.file. It's a full blown content type implementation, with dependencies on zope.app.form, providing browser view code, browser menus and quite a bit of zope.app integration. It's test setup needs a full blown ZODB and publisher environment.
ACTION: I'd remove this from the ZTK until someone is willing to refactor it to provide a minimal file implementation.
+1
zope.formlib and friends
zope.formlib depends on zope.app.form which in turn depends on many zope.app packages. zope.html and zope.mimetype both depend on zope.formlib or zope.app.form.
Various people myself included looked at the zope.formlib / zope.app.form split to see if it can be refactored in a sensible way. I think the conclusion has so far been: there's just no way. There isn't a sensible set of basic principles or interfaces in formlib, that can form a base for a higher level zope.app.form. All the packages using formlib today actually make use of the widgets in zope.app.form and thus basically on the entire functionality.
I'm probably not seeing something, but wouldn't we be able to just move the widgets from zope.app.form into zope.formlib? The non-test dependencies of zope.app.form don't look that bad.
zope.testbrowser
This package offers functional browser tests and consequently needs a way to set up a ZODB and publisher with some default application configuration. I don't see how this can be achieved without depending on a specific application environment like zope.app.appsetup or Zope2/App. Zope2 depends on the package and it makes sense to include it on the application server level - but not on a toolkit level for building frameworks.
ACTION: I'd suggest to drop this package from the ZTK.
If there are multiple frameworks that use this (and there are, Zope 2, Grok, Zope 3 apps), shouldn't just drop it. We could move it into the 'under review' status or something. Regards, Martijn