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

[Paul Winkler]

On Wed, Nov 30, 2005 at 08:54:34PM -0000, Martin Aspeli wrote:
> >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.
> 
> Okay, so say the template designer has a big <div id="documentBody"> where  
> I am to put the document body. There is a different way of displaying that  
> for each content type. Inside that, I need, say, an <h1>, a couple of  
> <div>s and whole bunch of structural content for the actual document body.
> 
> 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

In case it's not clear, the print statements you often see in
Meld examples are just for command-line demo purposes.
A Meld object can be converted to x(h)tml by treating it as a string.

So in my hypothetical Zope / Script (Python) implementation,
the script would simply return the Meld object. The template
might come from a File instance. Like so:

## Script (Python) "foo_form"

from Products.Meld2 import Meld2
foo_form = Meld2(container.foo_form_template())
main = Meld2(context.main_template())

# ... using elements of main template and populating data goes here...

return foo_form

I think this discussion would be a lot more productive if I had
more full-featured examples to share. Working on that.
This is all at a *very* early stage.
 
> To be honest, I think I'm just a little uncomfortable with the  
> "procedural" approach to templating, It seems a little poorly structured  
> and prone to error, e.g. if I'd have to manipulate things in loops etc. 

How is a python loop more error-prone than tal:repeat?

> Basically, instead of relying on syntax (e.g. TAL) that lets me declare  
> what I want (put X here, loop over these), I'd have to rely on patterns  
> and APIs in a fully-featured programming language. It seems a bit easy to  
> miss a tag or treat something as iterable when it wasn't meant to.

I'm having trouble connecting this fear with anything that's actually in
Meld2.  I don't know what you mean by "miss a tag".  And if you treat
something as iterable that isn't, you get a TypeError as always in
Python code. When do you think that would happen, and how is that harder
to debug than ZPT?
 
> To that extent, I prefer the separation of concerns in a scenario with  
> Five views (i.e. view classes bound to logic, individually unit testable,  
> well-defined boundary between view logic and presentation) and TAL  
> expressions only. 

Hey, I like that stuff too :-)

> And again, for the "site themer" role, a layer on top of  
> that like what Paul is describing sounds appealing.

I'm a Paul too :-)
 
> That's not to say your work isn't intriguing though. I reserve the right  
> to become convinced. :-)

I reserve the right to decide it's a terrible idea :-)
I think it will take a real project to determine that.

And I don't expect this to have rapid uptake in the Zope world. Backward
compatibility is king and I don't have a story for leveraging existing
ZPT.

-- 

Paul Winkler
http://www.slinkp.com