On Feb 24, 2009, at 11:46 AM, Martijn Faassen wrote:
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/
I disagree strongly with many of the assertions made in these articles. (I can't judge the pipeline proposal, since it is only fleshed out in code.) While I do think zope.publisher has some problems, they aren't the same problems that shane sees. ...
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.
I'd like to see see some specific examples. In general, in Zope 3, we've advocated a separation of model and application code from presentation code. Presentation code is going to depend on whatever presentation framework it uses.
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.
I'm not sure why this matters. BTW, I suspect we're more concerned about odd dependencies *of* zope.publisher, like zope.location. It might be better to focus on some of those. I'd also be in favor of separating out less central parts, like support for xml-rpc.
We got two kinds of browser-based code we should distinguish between:
* ZMI code
There shouldn't be anything in zope.publisher that depends on the ZMI.
* 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 sure what you're saying. If an application package has presentation code mixed into it and if there is a desire to use that application code in a context without presentation, I'd separate the presentation code from the application code. The presentation code would depend on zope.publisher. The application code wouldn't.
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?
I don't know what you mean by "these" above. Jim -- Jim Fulton Zope Corporation