[Zope-dev] zope.container analysis

[Martijn Faassen]

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