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

[Gary Poster]

On Apr 16, 2007, at 12:18 PM, Philipp von Weitershausen wrote:

> 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

cool

> 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).

yup, precisely

>> (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.

Yes, I'll specify __iter__.

> (M-x replace-string RET IRequest RET IResult RET)

Oh, you emacs guys. ;-).  Yup.

>> 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

Yes, I saw that too.  I wonder if he does dependency stuff, as  
zc.resourcelibrary does now; I find that quite nice, and will still  
want it even when the majority of the package's code can evaporate  
because of IResult.

Gary