[Zope-CMF] Meld2, was Re: Proposal for hooking rendering

[Paul Winkler]

(changing the subject to avoid hijacking Paul E.'s thread any further)

On Wed, Nov 30, 2005 at 02:48:12PM +0000, Martin Aspeli wrote:
> 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.

Certainly not. Reusing bits of a meld is actually really trivial.
(And I'd be surprised if you've never needed to copy and paste a whole 
third-party ZPT because it didn't give you granular enough macros to do
the job. This is *very* common in the CMF and Plone world.) 

I need to post some reuse examples.... OK, here's a simple one:
http://w

> The thing that scares me most, though, is that in the Meld scenario, building
> the UI for the developer is very "precedural". 

Yes, by intent. It's definitely a whole different mindset.

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

It's a lot looser than knowing the whole DOM. You just need to know
the IDs. And in some cases, only when an id is used in multiple
places, you will need to know the id of its parent. That's the only
mental model you need.  You don't need to have any idea what
the tags are or how the page structure is arranged. 

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

Note that in the PyMeld / Meld2 approach, I'm hoping that the
coupling between document structure and the processing code can be kept 
pretty loose, so you can redesign the page by moving blocks of
html around, and you can move an id from one kind of element to another
if you like; and in many cases the python code will still just work;
and when it doesn't, it should always be pretty trivial to fix.

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

Playing nice with existing code (e.g. huge amounts of ZPT) is
the killer problem here. I haven't thought much about it yet.
I'm still in the utopian dreaming phase.
First I need to be sure that doing templating this way is
actually a good idea at all :-)  My intuition is that PyMeld didn't
take off at least partly because as written it just wasn't convenient
enough to use; I could be wrong about that.
 
> 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.

"pure python" processing of x(h)tml is an explicit goal of Meld2, so I
guess we disagree. Note that this leaves the door wide open to other
processing in the pipeline, e.g. XSLT.

-- 

Paul Winkler
http://www.slinkp.com