[Zope-dev] zope.publisher dependencies

[Jim Fulton]

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