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

Chris McDonough chrism at plope.com
Thu Dec 1 13:03:20 EST 2005


On Nov 30, 2005, at 7:33 PM, Martin Aspeli wrote:

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

In general, and this might be totally obvious, but I think the idea  
of a meld-like system is to allow for truly minimal markup in html  
templates.  This was ZPT's original goal, but my experience at least  
has shown that even allowing minimal flow control and declaration  
inside the template (e.g tal:condition, tal:repeat, tal:define) has  
the practical effect of making it unlikely for effective  
roundtripping of the template between a designer and a programmer.

For my projects, I have found that besides filling slots of a main  
template with other dynamically generated pieces of HTML, I just  
don't use METAL very often.  I realize that this is not the case for  
systems like Plone, where it's used frequently.  But given my minimal  
usage, it makes me wonder if there's some "lessons-learned"-derived  
pattern/API that would make it dead-easy to define a "main template"  
with slots and replace those slots with pieces of meld-derived html,  
throwing away the capability to make it easy to allow for arbitrarily- 
nested macros as METAL allows.

- C



More information about the Zope-CMF mailing list