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:
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
> 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
> zope.browser package doesn't have the right name?
I don't know what you mean by "these" above.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -