On 5/14/09 6:09 PM, Chris McDonough wrote: > On 5/13/09 1:55 PM, Martijn Faassen wrote: >> Hi there, >> >> zope.app.publisher is depended on by quite a bit of code that uses the >> Zope Toolkit, as it defines brower:view and browser:resource and the like. >> >> Unfortunately zope.app.publisher currently depends on more than 60 >> packages. This is rather excessive, and we'd like to cut down on this. >> >> Also interesting about zope.app.publisher is that while it defines a >> 'browser' directory it actually doesn't contain any ZMI code; instead >> ZCML directives are defined there. Refactoring so the ZMI isn't around >> anymore is usually a good first step, but that's not needed here. >> >> If you look at the dependency graph for zope.app.publisher the task of >> fixing this looks daunting: >> >> http://startifact.com/depgraphs/zope.app.publisher.svg >> >> But now please observe the following: >> >> http://startifact.com/depgraphs/zope_app_publisher_cycles.svg >> >> This identifies the main cycles in that dependency graph. If we break >> those in the right way, we can cut down a lot of dependencies in one go. >> Getting rid of the zope.app.form and zope.formlib dependencies looks >> like a sensible step. >> >> From this little graph, it looks clear we could do some of the >> following things (research is needed to see how difficult they are): >> >> * cut the dependency of zope.app.publisher on zope.app.component >> >> * OR cut the dependency of zope.app.component on zope.formlib >> >> * cut the dependency of zope.app.publisher on zope.app.publication >> >> * OR cut the dependency of zope.app.component on zope.app.security >> >> * cut the dependency of zope.app.publisher on zope.app.publication >> >> * OR cut the dependency of zope.app.publication on zope.app.exception >> >> * OR cut the dependency of zope.app.exception on zope.formlib >> >> There are probably a few more options there, but given that small graph, >> you get the picture. >> >> Any volunteers to do this research on how hard some of these steps would >> look and report back here? Once we've discussed the options we can >> proceed fixing the problem. > > I did a bit of research on the direct "zope.app.*" dependencies of > zope.formlib. > > - I was able to get rid of a dependency on zope.app.container by > requiring zope.browser>=1.1 (which Tres released yesterday); > this package now has the ``IAdding`` interface that zope.formlib > relies upon. > > - I looked into its dependency on zope.app.pagetemplate. > It defines two "named templates" in its form.py module using > The ViewPageTemplateFile class from zope.app.pagetemplate. > Each is registered in its configure.zcml as adapter with the > name "default". I don't have enough zen to know what the intent > is here or whether the named templates could use > zope.pagetemplate instead. > > - I looked into its dependency on zope.app.form. It > essentially uses a bunch of interfaces from the > zope.app.form.interfaces package. I don't know whether it > would be reasonable to move all those interfaces > to zope.browser or somewhere else, but essentially > moving those interfaces to somewhere "neutral" > would break this particular dependency. > > - C
Wrt a possible future for zope.catalog, I think we might leave it be, and encourage framework writers to use repoze.catalog instead. For instance, a new "zope.app.catalog" package could be written that depends on repoze.catalog. repoze.catalog is a ZODB catalog implementation inspired by zope.catalog. It uses zope.index subclasses for its index implementations. It has a direct dependency on zope.index; that is actually its only direct dependency. (although zope.index depends on ZODB, so that obviously gets pulled down too when you install it, plus its transitives). The trick it uses to avoid inappropriate dependencies is to make the framework writer register event subscribers for IObjectModifiedEvent and its the framework's equivalent of "IIntIdRemovedEvent", etc instead of providing the handlers itself. A framework developer could wrap repoze.catalog in such a way that these things happened like they do in zope.catalog; just register appropriate subscribers. It also returns sets of integer docids rather than a "result set" that knows innately how to resolve these integer ids. A framework developer could obviously create a subclass or adapter that wrapped the catalog and did the object resolution. http://svn.repoze.org/repoze.catalog/trunk/ - C _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
