[Zope-dev] Re: Exposing the simple publisher (Re: Re: Reducing dependencies of zope.publisher)

[Chris McDonough]

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