Tonico Strasser wrote:
> Hi!
>
> Jean-Marc Orliaguet schrieb:
>
>> Anyway, pagelets or portlets whatever they called and no matter what
>> data they produce (structured data or raw HTML) must be "pipe-able"
>> through the rendering engine, i.e. they must return some data, the more
>> "ready HTML" the data is the less reusable it will be.
>
>
> Pipe-able, hmm. I think, *if* we could do define-slot and fill-slot
> stuff in Python code that would be very nice. We would have a "page"
> object that can "pipe" page components together.
>
yes, this is what cpsskins does:
- the "define-slot" is just a "cpsskins:slot" with a name identifier
('left', 'right', 'main' ...) which means that can be used on several pages.
- the "fill-slot" part has been the subject of the discussion the past
week in the "perspective" thread.
Currently the plan is to support the "perspective" way of filling slots
(1 perspective = 1 set of portlets) and the "local folder" way of
filling a slot, i.e. traversing the site starting from the site root to
the current folder, gathering all the portlets stored in each folder on
the path and displaying them into the slot that they belong to.
here is how the renderer works:
http://www.z3lab.org/sections/front-page/white-papers/draft-renderer/downloadFile/attachedFile/renderer-architecture.png
starting from the top node in the theme tree:
A) is the node a leaf?
=> YES: then render the node according to B)
=> NO: get the list of child nodes in the correct order, for every
node go to A)
B) for every filter associated to the node:
- is the filter is the first in the chain?
=> YES: then get the data from the leaf (getDisplayData())
=> NO: use the output of the previous filter in the chain and feed
it into the current filter
- if the filter is the last in the filter chain for that node, feed
the filtered data into the next renderer.
In this way, believe it or not, you can by changing a few lines in a
zcml file render a "theme editor" with all the AJAX stuff
http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/configuration/engines/editor/configure.zcml
or an HTML page ready to be displayed on a web page:
http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/configuration/engines/default/configure.zcml
90% of all the components are reused, simply they are wired together
differently.
> A simple example with boxes (sorry, Zope 2 script, don't kill me):
>
> ##
> page = context.Page(template=container.ZPT_A)
>
> # aggregate macro-defs from other page template
> page.macros.update(container.ZPT_B.macros)
>
> # create list of Box instances (not rendered HTML)
> b1 = container.box_a('demo', 'Demo', condition=some_condition)
> # box 2 takes b1 as input
> b2 = container.box_b('foo', 'Foo', some_arg=b1)
>
> left_boxes = [b1, b2]
>
> # make boxes available in PTs as 'lboxes'
> page.lboxes = left_boxes
>
> # now we have aggregated all informations
> # ready to render
>
> # calls pt_render of ZPT_A with extra context
> return page.render()
>
> ##
>
> ZPT_A:
>
> <page>
> <body metal:use-macro="macros/body"/>
> </page>
>
> ZPT_B:
>
> <body metal:define-macro="body">
> <!-- render boxes here -->
> <box metal:use-macro="macros/box_repeat"/>
> </body>
>
> box_repeat macro:
>
> <div class="box"
> metal:define-macro="box_repeat"
> tal:repeat="box lboxes"
> tal:attributes="id box/id">
> <h1 class="box-header"
> tal:content="box/title"/>
> <div class="box-body"
> metal:use-macro="box/macros/body|default"/>
> </div>
>
> Just for your inspiration.
>
> Tonico
>
>
yes, this is the ZPT way of doing it :-)
/JM
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
