[Zope3-dev] Re-revisiting IResult (for in-Zope pipelining)
Hi all! On 4/16/07, Gary Poster <[EMAIL PROTECTED]> 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]_. I'm here at the grok-sprint at EuroPython and we are looking into getting a pipeline hooked in to add theming to HTML output. [The idea of this is to add the theming, that is design, viewlets and so on, by imposing it on the HTML output, instead of including it from the template. This would open up for template independency, or even skipping templates completely for simple HTML and instead just outputting it.] We are looking for recommendations and visions on how to do this pipelining with IResults, because it's not entirely clear to us at the moment. Main worries are the questions of how to differ between results that need to be themed and those who don't, and also IResult seems to have to handle the encoding itself, which means we need to duplicate the encoding that is already going on in setResults. I have earlier (before IResult being made public) made a quick hack that inserts theming earlier in the process by replacing the BrowserPublication, maybe that's a better way to put theming? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: revisiting IResult (for in-Zope pipelining)
On Apr 16, 2007, at 3:55 PM, Philipp von Weitershausen wrote: On 16 Apr 2007, at 19:09 , Gary Poster wrote: I suppose there are four choices: (a) special case strings to make sure they are chunked the right way; (b) expect that the adapter result will be chunked the right way, so that someone returning a string will get bad performance and no error message; (c) puke if someone returns a string; or (d) log it to a file, but then do (a). I really don't like (b). A string is in fact iterable, so puking, as with (c), seems unpleasant. I'm ok with (d) but it seems excessively "naggy". Strings are *the* common case, so I prefer (a). I'm more concretely +1 on (a) now that I've spelled out these options. Since no one has given a true -1 on it, I will proceed with that, unless we get further discussion. Ok, as long as the WSGI-ish behaviour also works (that way it's easy to explain Nonzopistas). +1 Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: revisiting IResult (for in-Zope pipelining)
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]_. A general +1() for this whole effort! I have been having some thoughts recently about template-language neutral pipeline architecture for Zope 3. The basic idea would be to do something like XSLT rules or Genshi's match templates, and spell them out as Zope 3 views. These MatchViews would actually be views on a bit of a HTML page. The views are associated using XPath expressions, not through interface lookup. The MatchViews would be in a skin, and the skin has postprocessing logic which determines what to apply. This infrastructure would be very nice to have to start building this on top of. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: revisiting IResult (for in-Zope pipelining)
On 16 Apr 2007, at 19:09 , Gary Poster wrote: I suppose there are four choices: (a) special case strings to make sure they are chunked the right way; (b) expect that the adapter result will be chunked the right way, so that someone returning a string will get bad performance and no error message; (c) puke if someone returns a string; or (d) log it to a file, but then do (a). I really don't like (b). A string is in fact iterable, so puking, as with (c), seems unpleasant. I'm ok with (d) but it seems excessively "naggy". Strings are *the* common case, so I prefer (a). I'm more concretely +1 on (a) now that I've spelled out these options. Since no one has given a true -1 on it, I will proceed with that, unless we get further discussion. Ok, as long as the WSGI-ish behaviour also works (that way it's easy to explain Nonzopistas). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: revisiting IResult (for in-Zope pipelining)
> I'm more concretely +1 on (a) now that I've spelled out these > options. Since no one has given a true -1 on it, I will proceed with > that, unless we get further discussion. Thanks, Gary I am looking forward to using some of this! -Jim Washington ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: revisiting IResult (for in-Zope pipelining)
On Apr 16, 2007, at 12:30 PM, Philipp von Weitershausen wrote: Gary Poster wrote: 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 the schedule Christian mentioned, it seems like it would be possible. As you point out later, it doesn't make a huge difference to me practically because of the new egg distribution story. That said, if it made it to 3.4 in might encourage more exploration of the pipelining. It looks like the change is mostly mechanical for now (moving IResult to a more prominent place). Well, the IResult interface is different too, but yeah, this should be a pretty small job. (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. Great by me. :-) +1 to __iter__ as already mentioned in my other email. Yup, agreed. 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. I'm tempted to do this (i.e., special-case strings). I might talk with you about this off-line. I wouldn't mind keeping the IResult API WSGI-ish, meaning that you would have to return [output_to_html(lxml)] to make the above efficient, or chunk the strings and yield them. I'd characterize this as a -0 to my "temptation", I suppose. An over-lunch poll also got no conclusive opinions here one way or the other. I suppose there are four choices: (a) special case strings to make sure they are chunked the right way; (b) expect that the adapter result will be chunked the right way, so that someone returning a string will get bad performance and no error message; (c) puke if someone returns a string; or (d) log it to a file, but then do (a). I really don't like (b). A string is in fact iterable, so puking, as with (c), seems unpleasant. I'm ok with (d) but it seems excessively "naggy". Strings are *the* common case, so I prefer (a). I'm more concretely +1 on (a) now that I've spelled out these options. Since no one has given a true -1 on it, I will proceed with that, unless we get further discussion. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: revisiting IResult (for in-Zope pipelining)
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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: revisiting IResult (for in-Zope pipelining)
Gary Poster wrote: 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 the schedule Christian mentioned, it seems like it would be possible. As you point out later, it doesn't make a huge difference to me practically because of the new egg distribution story. That said, if it made it to 3.4 in might encourage more exploration of the pipelining. It looks like the change is mostly mechanical for now (moving IResult to a more prominent place). (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. Great by me. :-) +1 to __iter__ as already mentioned in my other email. 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. I'm tempted to do this (i.e., special-case strings). I might talk with you about this off-line. I wouldn't mind keeping the IResult API WSGI-ish, meaning that you would have to return [output_to_html(lxml)] to make the above efficient, or chunk the strings and yield them. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: revisiting IResult (for in-Zope pipelining)
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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
