On Mar 25, 2008, at 4:41 PM, Chris McDonough wrote:
...
Two nits:
- I don't like the fact that zope.publisher.publish uses the
"setResult" API of the request to handle the result returned by the
published object..
You mean the response....
why wouldn't it just return the result?
Because the response object is likely to do additional processing. It
is likely to set response headers at a minimum, but it may do much more.
Maybe this dance was cargo-culted over from Zope2.
I don't think so.
- I don't like that the request handles traversal.
It doesn't do much more than break the path into segments. All of the
actual traversal is performed by the publication. The publication
doesn't have to consume one segment at a time. It can consume the
entire path on the first traversal if it wants to. It can also do
traversal during initial object computation.
This also smells like it was cargo-culted from Z2.
I don't care for this characterization. When we did the Zope 3
publisher, we borrowed heavily from the Zope 2 one. The Zope 2
publisher is pretty heavily battle tested. I like the fact that
traversal is done a step at a time. It allows me to distribute the
traversal logic. If an application wants to traverse on the URL as a
whole, they can do that in the initial object selection.
Why shouldn't the publication itself do traversal?
It does,
Traversal is extremely policy-laden, why break the code that
implements that policy up so that you need "matching" request and
publication objects?
You don't. The request part of traversal is very general and only
protocol specific. To my knowledge, no one has ever written a custom
request to implement custom application policy. AFAIK, the publication
API is sufficient.
BTW, I don't claim that zope.publisher is flawless. I'd be happy to
see some discussion of it's strengths and weaknesses for the purpose
of making it better. I think my biggest regret is changing the
request and response APIs as much from those in Zope 2 as we did. I
think it would be interesting to look at how difficult it would be to
reunify the Zope 2 and Zope 3 request and response APIs. It might
also be interesting to look at a broader unification as Ian Bicking
has made some movement toward.
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 )
