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/ > > http://shane.willowrise.com/archives/zopepipeline/
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 _______________________________________________ Zope-Dev maillist - Zope-Dev@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 )
