On Mar 25, 2008, at 5:05 PM, Jim Fulton wrote:
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....
Yes, thank you.
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.
Why shouldn't the publication be responsible for setting response
headers based on the result and doing that additional processing?
- 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.
That's not how zope.publisher:publish reads, though:
request.processInputs()
publication.beforeTraversal(request)
obj = publication.getApplication(request)
obj = request.traverse(obj)
publication.afterTraversal(request, obj)
result = publication.callObject(request, obj)
The Z3 request.traverse implementation happens to delegate back to the
publication using method calls against its "self.publication" attr.
Isn't this kind of convoluted? Maybe it should just be
publication.traverse(request, obj) to match the other API methods of a
publication? e.g.:
request.processInputs()
publication.beforeTraversal(request)
obj = publication.getApplication(request)
obj = publication.traverse(request, obj)
publication.afterTraversal(request, obj)
result = publication.callObject(request, obj)
This also smells like it was cargo-culted from Z2.
I don't care for this characterization.
Sorry, no harm intended.
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.
Sure, no argument there, I'm really just arguing against publish.py
delegating to a request's traverse method.
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.
I agree that the IPublication API is correct. I'd just prefer that
the request not be responsible for performing top-level traversal
dispatch which then must call *back in* to the publication.
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.
Yup.
- C
_______________________________________________
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 )