[Zope3-dev] revisiting IResult (for in-Zope pipelining)

[Jim Fulton]

On Apr 15, 2007, at 9:51 PM, Gary Poster wrote:

> The work that Jim Washington and David Pratt have started recently  
> to make lxml an XHTML generator/ZPT replacement [#1]_ has really  
> excited me.  It would be *great* with in-Zope pipelines [#2]_.
>
> IResult (zope/publisher/http.py, about line 600) has been the  
> hidden, private, don't-use-it-because-it's-going-away tool with  
> which you can build pipelines since before Dec. 2005 [#3]_  I know  
> at least a couple of people who haven't explored the idea of using  
> it for a pipeline, despite interest, simply because the IResult  
> interface was private.
>
> Can we quickly figure out a reasonable way to make the new,  
> improved interface ready for 3.4?

I don't know if it is too late for 3.4.


> With it there, competitively or collaboratively, we can write in- 
> Zope pipelines as standalone packages, and "may the best pipeline  
> win".  Or we can just get a start with some small, cool lxml stuff.
>
> So what should the public API be?
>
> Here are two emails Jim (Fulton) wrote, corresponding with  
> Phillipp, about the thoughts behind IResult.
>
> http://mail.zope.org/pipermail/zope3-dev/2005-December/016778.html
> http://mail.zope.org/pipermail/zope3-dev/2005-December/016796.html
>
> Talking with Jim about this recently, he effectively questioned  
> this bullet point from the first email I linked:
>
> """
> - An adapter may need to affect outut headers, so IResult
>    needed to provide header data.
> """
>
> His question was, since the adaptation gets the request, why not  
> just have the adapter set the headers directly with request.response?
>
> That line of reasoning appeals to me.

Yup. Thanks for gathering all of this historical information  
together.  I think my original qualms about IResult had to do with  
the controversy surrounding it at the time.

>
> So, as a strawman, I propose that we make a public interface in  
> zope.publisher called IResult:
>
> class IResult(zope.interface.Interface):
> 	"""An iterable that provides the body data of the response.
>         For simplicity, an adapter to this interface may in fact  
> return
>         any iterable, without needing to strictly have the iterable
>         provide IResult."""

(Very minot note, this violates Python docstring style.  A multi-line  
docscrine should start with a single-line summary followed by a blank  
line.

> (I don't define __iter__ explicitly since I've been reminded too  
> many times that __getitem__ is still a workable iteration protocol.)

I don't agree.  Support by Python for __getitem__-based iteration is  
for backward compatibility. New code should not use __getitem__, but  
should use __iter__/next.  It would be clearer IMO to include  
__iter__ in the interface.


> Then we look up the IResult using the same multiadaptation of  
> (result, request) we have now, which makes it possible to set  
> headers in the adapter if desired.
>
> An IResult adapter could then be as simple as this:
>
> @zope.interface.implementer(zope.publisher.interfaces.http.IResult)
> @zope.component.adapter(
>     SomeCoolLXMLThing,
>     zope.pubisher.interfaces.browser.IBrowserRequest)
> def postprocessLXML(lxml, request):
>     do_some_cool_transformation(lxml)
>     return output_to_html(lxml)

Assuming that output_to_html returns a string, we should not  
encourage this unless we say that the publisher is going to special- 
case strings to iterate over them efficiently.


> and it might do a bit of request.response.setHeader(...) calls too,  
> if appropriate.

Yup.

> We would delete the private IResult entirely, without deprecation  
> (I argue that the warning in the doc string is pretty supportive of  
> this).

Yup.

...

> Votes?

Aside from 3.4 timing, +1.  I don't know if this can be done for 3.4.

Maybe this should be done in a post-3.4 zope.publisher release.

Thanks again for championing this.

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org