Stephan Richter wrote:
On Friday 15 May 2009, Martijn Faassen wrote:
It's tempting to start pushing more interfaces (and exceptions) down into zope.browser to break dependencies further. It does run the risk of turning zope.browser into a bit of a mash though. Perhaps that's worth it. Opinions, anyone?
zope.browser should not become an iface garbage collector. I think that interfaces not related to browser code deserve a new interfaces package.
Sure, that's why I said it's tempting, not that we should do it. When refactoring for dependency cleanup, we should do mechanical analysis about what we could move. We should also always consider whether moving it makes enough sense. And we should consider the goals of moving anything. Chris did the mostly mechanical analysis but didn't speak much about goals. Now I'll do a bit of "does moving stuff make sense" analysis: I think these relate to browser code: * browser.IBrowserRequest, * browser.IBrowserPublisher * NotFound * IDefaultViewName, * IPublishTraverse This one doesn't: * xmlrpc.IXMLRPCPublisher These don't seem to either: * ITraversable * IContainmentRoot I'm don't think there's a clear case to move any of these, however - these interfaces belong in their packages, and moving these interfaces down into zope.browser would move assumptions into zope.browser about the way the publisher works, and we'd still depend on this stuff with zope.container. Let's think about goals. A possible goal is that we'd like to make zope.container independent from zope.publisher and zope.traversing. This way people who use other traversal and publication mechanisms could still use zope.container's implementation. I think there are realistic chances alternative publication and traversal mechanisms will arise, so I think this is a realistic goal at least to consider. Let's look again at zope.container in that light. It depends on zope.publisher and zope.traversing to support traversing into the container by the publisher. The direct dependencies are: * some test depencencies. these are easiest to get rid of * bits of configuration in configure.zcml that set up the item traverser * related to that, bits of implementation in traversal.py that implement this traversal behavior. * For zope.traversal additionally some of this code is set up in zope.container.testing for reuse. If we wanted to make zope.container agnostic about traversal and the publisher, we'd need to move this code somewhere else. I cannot think of an existing package for this (anyone?). Lacking that, I'd suggest a new package, zope.containertraversing or something like that. That is one of these new packages some people object to. :) It would have a clear focus however: equipping the container with traversal behavior so it works with the zope publisher. Alternatively we could keep the code in zope.container and only enable it if zope.traversing and zope.publisher are installed, much like what Chris did with zope.app.dependable. It does worry me a little that this makes the code a bit harder to reason about however, plus it leaves a module in place people who know nothing about the publisher can still run into. Perhaps an acceptable trade off, perhaps not. Looking at zope.container, cutting out zope.publisher and zope.traversing (or making them optional) would allow us to cut the following from zope.container's dependency graph: zope.traversing zope.publisher zope.i18n zope.exceptions zope.authentication zope.browser Regards, Martijn