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 Fulton
Zope Corporation

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to