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]_.
So, as a strawman, I propose that we make a public interface in
zope.publisher called IResult:
"""An iterable that provides the body data of the response.
For simplicity, an adapter to this interface may in fact
any iterable, without needing to strictly have the iterable
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.
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:
def postprocessLXML(lxml, request):
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
.. [#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
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.
Zope3-dev mailing list