[Zope-dev] package dependency refactoring progress report
shane at hathawaymix.org
Sat May 23 03:24:42 EDT 2009
Martijn Faassen wrote:
> So, the only dependency cycles left in zope.app.publisher are these:
> zope.app.publisher <--> zope.app.publication <--> zope.app.http
I fixed those tonight. On the trunk, there are no longer any
dependencies between zope.app.publisher, zope.app.publication, and
zope.app.http, except testing dependencies.
Here is a summary of what I did:
- Moved the publication traversal code to zope.traversing and simplified
it from 3 classes to 1. This did not increase the dependencies of
zope.traversing at all, since publication traversal is only slightly
different from the traversal logic already in zope.traversing. It also
opens the doors for someday moving the gnarly traversal code in
zope.publisher to something saner in zope.traversing.
- Moved an XML-RPC view registration from zope.app.publisher to
- Moved IHTTPException, IMethodNotAllowed, and the MethodNotAllowed
exception class to zope.publisher.interfaces.http. This move decoupled
zope.app.http from zope.app.publication.
- Moved getDefaultViewName() and queryDefaultViewName() to
zope.publisher.defaultview. If you look at the commit messages, you'll
see that I first attempted a different move that included the
<browser:defaultView> handler, but that move turned out wrong for other
packages and I reverted it.
- I used zope.deferred to deprecate things I moved from
zope.app.publication, zope.app.publisher, and zope.app.http. Are there
any objections to using zope.deferred in those packages?
In all, I changed 6 packages. Should I release them now, or should I
look for other dependencies we might clean up at the same time? The
changed packages are:
zope.app.zcmlfiles (3.5.5; bugfix only)
More information about the Zope-Dev