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

[Gary Poster]

On Jul 13, 2007, at 6:06 AM, Lennart Regebro wrote:

> On 7/13/07, Gary Poster <gary at zope.com> 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