[Zope-dev] zope.publisher dependencies

[Martijn Faassen]

Hey,

On Tue, Feb 24, 2009 at 6:39 PM, Jim Fulton <jim at zope.com> wrote:
[Shane's blog entries]
> 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.

That's not a very constructive statement. :) Which assertions do you
disagree with, and why? And what problems do you think the publication
machinery of Zope has?

The main problem I have with the zope publication machinery is that
after all these years of using it I *still* get lost in it regularly.
A more regular architecture that can be traced more easily would not
only allow better understanding on my part, but might also allow us to
more easily selectively replace or remove bits of it.

>> 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.

If Grok wants to switch to zope.pipeline it'd be pulling in code that
would never be used. That code is a harmful distraction.

> 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.

Some of the bits that Shane is talking about *are* those dependencies
on zope.location. zope.location is a pretty central bit that ends up
being used by huge parts of the framework. We've already regularized
its dependencies a few weeks ago so it's not as terrible to depend on
it as it used to be.

>> 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.

I'm just trying to make clear we have framework code that builds on
bits of zope.publisher that might not need to build on as much of it
as it does now. I think framework code that is presentation-related
and code that is there to build a specific user interface the ZMI can
receive a different treatment in dependency analysis.

>> 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.

The three bits Shane is talking about:

   - zope.publisher.interfaces

   - zope.publisher.browser.Browser{View|Page}

   - zope.publisher.browser.TestRequest

I'd prefer them to be off in a package by themselves if they can be
instead of being sub-packages of zope.publisher, since they don't
depend on zope.publisher.

Regards,

Martijn