[Zope-CMF] Proposal for hooking rendering

Paul Winkler pw_lists at slinkp.com
Tue Nov 29 11:31:29 EST 2005


On Tue, Nov 29, 2005 at 09:34:09AM +0100, Paul Everitt wrote:
> 
> Hi all.  I'd like to make a small proposal to enable investigation of a 
> larger proposal.
> 
> I'm generally interested in the ideas of pipelines for markup rendering. 
>   Specifically, I'm interested in separating the concerns of skin 
> scripters and corporate ID people into two logical parts:
> 
> 
> http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SiteThemes
(snip)

Interesting stuff. One thing that immediately occurs to me:
""" 4) Opt-in. All templates in all core code and all add-on products have
to decipher the under-documented, un-enforced system of macros and slots
in order to leverage the corporate id work in main_template. If you want
to apply a consistent look and feel on all pages, you should be able to
impose it, whether the view template agreed or not
...
 3) Universal. The corporate id is not optional. It gets imposed on
every page in a site.
"""

That goes too far IMO. Opt-in is a pain, but if you remove it, we need
to add an "opt-out" feature. Consider for example links that launch
pop-ups with some snippet of information in a smaller window. You
frequently want these to have a very stripped down look-and-feel. This
can be used for e.g. context help. I've seen a lot of sites like this
and worked on some.

> http://www.zope.org/Members/zopepaul/zopesitethemesdiagram.png
> 
> This isn't revolutionary stuff.  It's a meme that appears in Typo3 and a 
> few Python templating systems.

(snip)

> At the EuroPython sprint, Tres coded up a nice little ZCML pipeline 
> product that hooked Zope 3.1's publication events.  However, this event 
> isn't usable in Five 1.3.
> 
> Here's my small proposal for a near-term CMF 1.x release:
> 
> 1) In CMFCore/FSPageTemplate.py, modify its pt_render or _exec.
> 
> 2) Check to see if there is a configured pipeline tool.
> 
> 3) If so, run the result of:
> 
>   result = self.pt_render(extra_context=bound_names)
> 
> ...through the tool and return it.

So this wouldn't work for PageTemplate instances in the ZODB,
e.g. in portal_skins/custom/ ?
 
> Things I'm not proposing:
> 
> 1) CMF out-of-the-box contains any tool nor any pipelines.
> 
> 2) I'm not asking others to do the work on these.  I'll learn enough to 
> make some prototypes.
> 
> Before I write a proper proposal, though, I'd like to find out if there 
> is basic interest:
> 
> 1) Does the CMF have an interest in experimenting with ideas on 
> splitting corporate ID responsibilities from product skin responsibilities?

To me, sure. Anything with the potential to reduce complexity of
main_template and increase cohesion is interesting :)

Incidentally, I'm intrigued that you latched onto the idea
of leveraging pure x(h)tml and just using the "id" attribute to identify
the boxes.  I don't mean to derail your thread, but I think we're
annoyed by some of the same misfeatures of the current big-complex-ZPT
approach in CMF, but we go in different directions with our ideas. Yours
is focused on leveraging and improving existing work with minimal pain,
mine is a bit more pie-in-the sky :)

In some recent discussions(1,2,3) about templating, I've grown
increasingly convinced that ZPT is too complex, and that I'd prefer
something along the lines of PyMeld(4).

But PyMeld (and PyMeldLite as shipped with SpamBayes) has a few serious
practical flaws IMO, so with input from various folks I've whipped up a
proposal(5) and prototype (6) called Meld2. 
 
The main "feature" is that the templates themselves are
pure stupid x(h)tml which do no work whatsoever.  
Nodes of interest are identified by tagging them with an identifier.
This could be the standard html "id" attribute, but I think that's a bit
heavily loaded already (it's used frequently for both CSS and
javascript), so I'm currently favoring something else like e.g.
"meld:id"... but that's optional, just using "id" works fine
(and that's what PyMeld does).

You then use a *very* simple python API to read the x(h)tml and
transform it into the desired output.  Neither the designer nor the
programmer has to learn a new language.  All the use cases of 
ZPT are handled easily by the python API (filling content, repeating and
populating clones of a node, removing or replacing nodes, re-using and
extending a "master" template, etc).  Some important stuff has not yet
been thought about (i18n, quoting).

Possibly of particular interest to you: The output is always valid
input, so a pipeline approach is easy to set up.

This is all "pure" python at the moment, I have not worked out
a Zope integration yet.


(1) http://plope.com/Members/chrism/html_sucks
(2) http://plope.com/Members/casey/tal_inheritance 
(3) http://plope.com/Members/slinkp/meld2_update
(4) PyMeld: http://www.entrian.com/PyMeld/
(5) http://slinkp.com/code/zopestuff/templates
(6) http://slinkp.com/code/zopestuff/templates/Meld2.py

-- 

Paul Winkler
http://www.slinkp.com


More information about the Zope-CMF mailing list