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
