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?
He has, though perhaps not in an obvious place for you: http://shane.willowrise.com/archives/repozublisher/ http://shane.willowrise.com/archives/redesign-of-zopepublisher/ http://shane.willowrise.com/archives/zopepipeline/ http://shane.willowrise.com/archives/limits-of-zopepipeline/
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.
Shane, how integrated is code that relies on the pieces in zope.publisher you identified into their own packages? I have the impression it'll be much harder to go that way than factor bits out of zope.publisher instead. Especially as zope.publisher contains stuff that Shane has no use for with zope.pipeline, and we'd still be pulling it in if we didn't do the refactoring. We got two kinds of browser-based code we should distinguish between: * ZMI code * framework code that supports the browser To get rid of ZMI code, a pattern that works fairly well is to refactor everything *else* out of the package and leave the ZMI code in its original location, with backwards compatibility imports in place. zope.app.* packages frequently can get this kind of treatment. Other framework code that supports the browser is much like any other framework code. Some packages need to be aware of the browser in order to perform their role as framework component at all. If those packages can rely on *less* code that would be an improvement. I'm not very much in favor of making these sub-packages of zope.publisher though, as to me a sub-package structure tends to make an implication that it relies on the outer package, which in this case it doesn't. I'd rather see zope.browser take this role. Perhaps the current zope.browser package doesn't have the right name? Regards, Martijn