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:[EMAIL PROTECTED] Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope3-dev mailing list
[email protected]
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
