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

[Philipp von Weitershausen]

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]_.
> 
[snip]
> 
> 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."""

+1

I'm particularly fond of making this official because we've been 
thinking about how to do skinning in Grok in way that's not specific to 
a templating engine. Being able to return XML tree datastructures (or 
really any object) from views would allow us to effectively do the 
theming (transformation of XML trees) in the IResult adapter (before 
doing the serialization).

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

It's workable, but all elementary types that are iterable support 
__iter__. I see no reason why we shouldn't require it here.


(M-x replace-string RET IRequest RET IResult RET)
> Then we look up the IRequest 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)
> 
> and it might do a bit of request.response.setHeader(...) calls too, if 
> appropriate.
> 
> We would delete the private IRequest entirely, without deprecation (I 
> argue that the warning in the doc string is pretty supportive of this).

+0

> .. [#2] I want views to be able to return lxml structures, and widgets 
> to be able to return lxml structures.  I want the publisher to have a 
> pipeline to be able to transform the output of a view with o-wrap, and 
> zc.resourcelibrary-like postprocessing done right.  I want pages to be 
> able to cache their lxml output, while then an o-wrap gets 
> personalized/more timely bits for the o-wrap.  And so on.

And Grok wants the theming as part of the pipeline :). I supposed it's 
something like zc.resourcelibrary on steroids.

Btw, interesting that you bring up zc.resourcelibrary as an example. Ian 
Bicking recently blogged about doing post-rendering transformations to 
insert JavaScript [1]. He specifically talks about a form context 
(widgets needing JavaScript).

[1] http://blog.ianbicking.org/lxml-transformations.html


-- 
http://worldcookery.com -- Professional Zope documentation and training