[Zope-dev] zope.publisher dependencies

[Martijn Faassen]

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