faassen at startifact
May 15, 2009, 7:24 AM
Post #7 of 8
(541 views)
Permalink
|
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
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]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 )
|
