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

[Martin Aspeli]

>> Do I output those variable elements with python with print statements?
>
> Good lord, no!  You'd do the same thing you do today with ZPT: Write a
> template for each content type.
>
> Each one would be used by an associated bit of Python code, which in a
> Zope implementation of Meld2 could be a Script (Python).  The script
> would take nodes from the main template and insert them into
> the content type template, just like you use ZPT macros.
> Filling "slots" is easy too.
>
> My reuse example was intended to make this clear.
> If you don't want to grab the tarball I just posted it in a comment
> here:
> http://plope.com/Members/slinkp/meld2_update

I had a look at this now. To be honest, I think it's probably a step back  
 from the METAL approach to reuse, because, to my mind, at least, the  
"template" and "slot" concepts are logically different, but they're marked  
up the same way, using meld:id. If you look at the reuse_derived.xhtml  
template, there's no way apart from the comments to realise what's dummy  
content and what will be integrated into the main page. For the same  
reason, I find the python confusing - I have to remember to save tag (the  
title), then replace the bulk of my template, then re-insert the saved  
tag. This is what I mean by having to learn patterns and not syntax. It  
seems to me that this pattern would be so common it should be handled by  
the framework, not by my code, at least. But then you'll start inventing  
more syntax in the template (probably).

The greater point, though, is that the page designer, in your example,  
would still be thinking just as carefully about how these templates  
interact as he would using METAL. In that case, having explicit syntax for  
it is probably better than letting the joining .py script do that logic  
(to avoid one in a dozen of such scripts for different content types  
making some silly mistake and compositing it slightly wrong... unless you  
start factoring out methods to do some of this replacement, but then you  
are simply displacing complexity, and displacing it away from the place  
where it logically occurs - in the template compositioning). And if I  
think about what that syntax may look like, the METAL syntax is actually  
pretty close to an ideal.

That said, this is slighly different from the simpler use case of simply  
replacing parts of a page. As a thought experiment, consider a system  
where the templates are like Meld2 XHTML pages with meld:id for  
placeholders where dynamic content goes, but that also allow the use of  
METAL for compositioning. Then again, I'm not quite sure how much that  
gains over using tal:replace="@view/something" and doing away with more  
the complex parts of TAL. Well, I suppose the complexity of tal:repeat,  
tal:condition etc. would be moved away from the template designer.

Martin

-- 
(muted)