Re: [Zope3-dev] Re: Re-revisiting IResult (for in-Zope pipelining)
On 7/13/07, Jim Washington <[EMAIL PROTECTED]> wrote: Doesn't the published object, being a view class, have context and request as instance variables? Well, yes. But these are also available directly in the Publication.callObect() method, and neither of them are available in the IResult, typically. -- 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: Re-revisiting IResult (for in-Zope pipelining)
On Jul 13, 2007, at 12:30 PM, Lennart Regebro wrote: On 7/13/07, Tres Seaver <[EMAIL PROTECTED]> wrote: You can't ask "upstream" to produce a thousand different pipelineables; the interface there needs to be dirt simple, and *always the same.*. In particular, you can't return unicode *or* a pipelineable: that puts the policy choice in the wrong place. Right. Also, after further discussion of the issues, which I'll try to put down in a sprint-report, we have concluded that the correct place to do the theming-pipeline is most likely in the BrowserPublication, because there you have access to the context as well as the published object typically (being a view class). Hm, too bad. Gary ___ 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: Re-revisiting IResult (for in-Zope pipelining)
Lennart Regebro wrote: > On 7/13/07, Tres Seaver <[EMAIL PROTECTED]> wrote: >> You can't ask "upstream" to produce a thousand different pipelineables; >> the interface there needs to be dirt simple, and *always the same.*. >> In particular, you can't return unicode *or* a pipelineable: that puts >> the policy choice in the wrong place. > > Right. Also, after further discussion of the issues, which I'll try to > put down in a sprint-report, we have concluded that the correct place > to do the theming-pipeline is most likely in the BrowserPublication, > because there you have access to the context as well as the published > object typically (being a view class). > Doesn't the published object, being a view class, have context and request as instance variables? object.context and object.request should work to access these things. Or am I missing something? -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: Re-revisiting IResult (for in-Zope pipelining)
On 7/13/07, Tres Seaver <[EMAIL PROTECTED]> wrote: You can't ask "upstream" to produce a thousand different pipelineables; the interface there needs to be dirt simple, and *always the same.*. In particular, you can't return unicode *or* a pipelineable: that puts the policy choice in the wrong place. Right. Also, after further discussion of the issues, which I'll try to put down in a sprint-report, we have concluded that the correct place to do the theming-pipeline is most likely in the BrowserPublication, because there you have access to the context as well as the published object typically (being a view class). -- 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: Re-revisiting IResult (for in-Zope pipelining)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: > On Jul 13, 2007, at 6:06 AM, Lennart Regebro wrote: > >> On 7/13/07, Gary Poster <[EMAIL PROTECTED]> wrote: 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, >>> I thought you'd return different objects, and rely on adapters. I'm >>> a bit surprised at the question, actually--what have I missed? >> Well, most HTML output is done by templates, which typically return >> unicode. I guess we can let the BrowerPublication to wrap the unicode >> in an object... > > No, the intent is that this is explicit in the view. > 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? >>> Doesn't appeal to me--feels like the hack that we did for >>> zc.resourcelibrary, in which the change to the system is much, much >>> too heavyweight (someday we'll convert it to using IResult, I >>> suspect)--but you're doing it. :-) >> Maybe. :-) >> But just after I pressed send I actually realized that one part of the >> theming is getting in viewlets therem which is quite difficult if you >> don't have the context, which actually again points at the Publication >> being the right place to do this. Or am I missing something? > > Here's what I was thinking. > > If you want a view to return an unprocessed unicode value (or perhaps > "lightly processed") then have it return the value. The end. The > pipeline will do little or nothing to it. (zc.resourcelibrary might > look for "HTML-ness" in the string and try to insert, but that's it). > > If you want it to be processed as part of a pipeline, then return an > object that has what you think the pipeline will need. For instance, > here's a very off-the-cuff version. There's a *lot* of room for > figuring out different ways for this to work, which is one of the > interesting bits, and why we've said, at least internally, "let a > thousand pipelines bloom"...and then presumably just a few of them > will settle down and win. You can't ask "upstream" to produce a thousand different pipelineables; the interface there needs to be dirt simple, and *always the same.*. In particular, you can't return unicode *or* a pipelineable: that puts the policy choice in the wrong place. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGl5P3+gerLs4ltQ4RAir2AJ0aVIIHgD4TsF23VA1fzsefalUV5QCfY9WM N2DuzN+/syLDKfz8YdzdYFk= =VBz5 -END PGP SIGNATURE- ___ 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: Re-revisiting IResult (for in-Zope pipelining)
On Jul 13, 2007, at 6:06 AM, Lennart Regebro wrote: On 7/13/07, Gary Poster <[EMAIL PROTECTED]> wrote: > 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, I thought you'd return different objects, and rely on adapters. I'm a bit surprised at the question, actually--what have I missed? Well, most HTML output is done by templates, which typically return unicode. I guess we can let the BrowerPublication to wrap the unicode in an object... No, the intent is that this is explicit in the view. > 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? Doesn't appeal to me--feels like the hack that we did for zc.resourcelibrary, in which the change to the system is much, much too heavyweight (someday we'll convert it to using IResult, I suspect)--but you're doing it. :-) Maybe. :-) But just after I pressed send I actually realized that one part of the theming is getting in viewlets therem which is quite difficult if you don't have the context, which actually again points at the Publication being the right place to do this. Or am I missing something? Here's what I was thinking. If you want a view to return an unprocessed unicode value (or perhaps "lightly processed") then have it return the value. The end. The pipeline will do little or nothing to it. (zc.resourcelibrary might look for "HTML-ness" in the string and try to insert, but that's it). If you want it to be processed as part of a pipeline, then return an object that has what you think the pipeline will need. For instance, here's a very off-the-cuff version. There's a *lot* of room for figuring out different ways for this to work, which is one of the interesting bits, and why we've said, at least internally, "let a thousand pipelines bloom"...and then presumably just a few of them will settle down and win. class MyPipelineInput(object): # you might have multiple ones of these, with different info. # this is one of the patterns you would be innovating on. # you might declare interfaces here, or even in the view...or even # in the pipeline. your pipeline might say "I keep on adapting until # I get a string, or until I've done more than X adaptations, which I # will regard as an infinite loop and so raise an error." Or you # might aim for another interface, or...or...or... def __init__(self, output, context, request): self.output = output self.context = context self.request = request # maybe you'd want to add __unicode__ so it could render as-is if desired? maybe add helpers to encode? class MyPipelineAwareView(BrowserPage): template = ...my template... def update(self): do stuff... def render(self): output stuff... def __call__(self): self.update() return MyPipelineInput(self.render(), self.context, self.request) As another variation, and one that made me excited, the view would return an lxml object, and you would adapt on that...which might eventually turn into a different kind of object, like the `MyPipelineInput` above, for further, different adaptation. You could also send a wrapper of the lxml object--even using a generic one like MyPipelineInput that then had an adapter that did a second dispatch on both itself and the output (and the request? and the context?) There are a lot of interesting variations possible here. We'll need to experiment for awhile to see what works, what is simple, and so on. Gary ___ 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: Re-revisiting IResult (for in-Zope pipelining)
On 7/13/07, Gary Poster <[EMAIL PROTECTED]> wrote: > 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, I thought you'd return different objects, and rely on adapters. I'm a bit surprised at the question, actually--what have I missed? Well, most HTML output is done by templates, which typically return unicode. I guess we can let the BrowerPublication to wrap the unicode in an object... > 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? Doesn't appeal to me--feels like the hack that we did for zc.resourcelibrary, in which the change to the system is much, much too heavyweight (someday we'll convert it to using IResult, I suspect)--but you're doing it. :-) Maybe. :-) But just after I pressed send I actually realized that one part of the theming is getting in viewlets therem which is quite difficult if you don't have the context, which actually again points at the Publication being the right place to do this. Or am I missing something? -- 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: Re-revisiting IResult (for in-Zope pipelining)
On Jul 13, 2007, at 5:40 AM, Lennart Regebro wrote: 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, I thought you'd return different objects, and rely on adapters. I'm a bit surprised at the question, actually--what have I missed? 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 think the responsibility is appropriate: IResult should be responsible for encoding, because who knows what it wants to return. Perhaps the factoring could be improved in the future, so that the encoding code could be a function that setResults uses, and your custom IResult adapter can too. For now, it hardly seems like a show- stopper. 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? Doesn't appeal to me--feels like the hack that we did for zc.resourcelibrary, in which the change to the system is much, much too heavyweight (someday we'll convert it to using IResult, I suspect)--but you're doing it. :-) Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
