[Zope-CMF] Re: Proposal for hooking rendering

[Martin Aspeli]

Paul Winkler <pw_lists at ...> writes:

> 
> 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 
> To me, sure. Anything with the potential to reduce complexity of
> main_template and increase cohesion is interesting :)

> 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. 

I think the idea that the main template/look-and-feel of the site should be
all-HTML is quite a good one, and certainly one likely to please the site
designers out there. Note that the decoupling still isn't complete, at least 
not
in the re-theme scenario, because the Meld approach still depends on certain
attributes being present (meld:id) and having at least some common structure
(e.g. it expects it to be a table). Probably those restrictions are easier to
swallow than learning a whole new syntax, though!

What a pure-play Meld approach doesn't give us, however, is the ability to
modularise and re-use elements of the UI (i.e. if they are to be used in 
various
different places at different times), and it makes it difficult to partially
exend the template. At the moment I can write a macro once and use it in
different places, with a single .html template, that becomes a copy-and-paste 
job.

The thing that scares me most, though, is that in the Meld scenario, building
the UI for the developer is very "precedural". ZPT is nice in that it is
declarative: I want this value to go here. If we restrict our thinking to
structural HTML (divs and spans and h1s and such), the output of a ZPT is more
about presentation structure than presentation visuals. I declare a view of 
what
a document in my CMS looks like structurally (the header is above the 
descriptio
is above the title).

With python processing of a template, I'd have to build a fairly good mental
model of what that template looked like and perform processing on that node
tree. The link between my data and where that goes on the page is just a bunch
of python. As a developer, I'd certainly prefer the declarative approach, where
I can build the structure of the template  and specify in it where things go.

Furthermore, I'm a bit unsure where the line goes. If the original template 
said
nothing about documents and how they are structured, do I print html from my
python code to inject into that empty "main content" space? (ouch!) Do I get my
themeing guy to make a brand-new-and-consistent template for each of my content
types? 

That's what makes Paul's proposal attractive to me. These two things are
decoupled. Building the data-to-presentation-structure layer is still done
declaratively, in ZPT (and with Views in Z3/Five). There are still macros and
slots that are used to compose the final page and ensure re-use of most 
elements
on the page. The output is a single, structural view of the page.

The site themer then writes a template that transforms the output of my mostly
structural idea of presentation into his mostly visual idea: the corporate ID.

Okay, that was long. I guess the point is that I still think the decoupling 
from
developer/page composer to artist/site themer is a useful one, without having 
to
restrict developers purely to processing in python.

Martin> > 
> > 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
>