Jim Fulton wrote:
On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote:
I've been working on the dependencies to and from zope.publisher. Refining the dependencies should make it easier to integrate zope.pipeline when it's ready.
Can you elaborate on this a bit?
I've been discussing zope.pipeline on my blog. I am attempting to rebuild the publisher to make it easier to understand and customize. I think it's working out pretty well. zope.pipeline is intended to replace most of the implementation code in zope.publisher and zope.app.publication. To accomplish that, it looks like I ought to separate the implementations in zope.publisher from the specifications. Separating the zope.publisher.interfaces package would mostly accomplish that. After thinking this over last night, I realize that the idea to move BrowserView, BrowserPage, and TestRequest is driven by the desire to clarify the dependency graph. That's more complex than what I'm trying to do and I don't think I need to do that for zope.pipeline, so I'm going to withdraw from that part of the discussion for now.
I've noticed that nearly all packages that depend on zope.publisher depend only on a few pieces of it:
- zope.publisher.interfaces
- zope.publisher.browser.Browser{View|Page}
- zope.publisher.browser.TestRequest
I'd like to turn this around a little bit. Only browser-based code should depend on zope.publisher. This seems like a very reasonable dependency. It's like wxwindows UI code depending on wxwindows. Maybe the browser code should be factored out of the packages that depend on zoep.publisher so that only *that* code has the dependency and non-browser code doesn't.
I think things are already pretty well factored in that sense. Take zope.formlib, for example. It wouldn't make sense to separate zope.formlib into an abstract package and a browser package, because zope.formlib only makes sense for browsers. Shane