[Grok-dev] Re: RFC: Masterpage implementation without macros
Philipp von Weitershausen
philipp at weitershausen.de
Mon Apr 16 16:18:27 EDT 2007
Martijn Faassen wrote:
> Philipp von Weitershausen wrote:
>> Martijn Faassen wrote:
>>> We need to try some implementation work. Either lxml or Genshi should
>>> offer the tools to implement the xpath stuff. It also needs work to
>>> define what grok.skin() actually does and then to implement it.
>> I'm much in favour of having an XML-based pipeline (both lxml and
>> Genshi sound like they provide good tools here).
>> Gary Poster just proposed (see my response ) something on the
>> zope3-dev mailinglist to allow standard browser views to return
>> non-string objects which the publisher then adapts to IResult in order
>> to actually obtain a string.
> Just proposed? This:
> >  http://mail.zope.org/pipermail/zope3-dev/2005-December/016796.html
> Goes back to december 2005. :)
I phrased that wrongly. He was proposing to turn an implementation
detail of the publisher regarding the streaming of large data into a
general hook for view result transformation.
> Anyway, allowing the standard browser views to return something that
> needs to be adapted to IResult would allow us to return markup streams
> that could then possibly be post-processed. If we can at least hook into
> the right place of the publisher to do the post-processing?
That's what the IResult adapter is for. It multi-adapts
(return_value_of_a_view, request) and returns an iterable of text. If
return_value_of_a_view were an lxml tree, you could
* modify the tree (e.g. using Python API, XSLT, etc.)
* serialize the tree to a string
in that IResult adapter. Naturally, we can do the same thing with
different technologies (Genshi comes to mind).
> Meanwhile it looks like Kevin Smith's skin work on his branch can just
> go ahead, as we'll need it whatever we do. We should look into merging
http://worldcookery.com -- Professional Zope documentation and training
More information about the Grok-dev