[Web-SIG] HTMLTemplate

[Donovan Preston]

On Jun 2, 2005, at 8:58 PM, Phillip J. Eby wrote:

> At 08:13 AM 6/3/2005 +0530, Sridhar Ratna wrote:
>
>> On 6/3/05, mike bayer <mike_mp at zzzcomputing.com> wrote:
>>
>>>
>>> referring to this one:
>>>
>>> http://freespace.virgin.net/hamish.sanderson/htmltemplate.html
>>>
>>> it looks very cool and elegant, and clearly produces templates  
>>> that are
>>> super-clean.  however, I would wonder how convenient it really is to
>>>
>>
>> I see that as reduced and simplified version of Nevow templates -
>> http://www.nevow.com
>>
>
> I'd say more a crippled relative than a simplified version.

 From looking through it briefly this was my impression. I think I  
asked HAS when he created it why he didn't use Nevow, and I think the  
answer was mostly because he just wanted to create static HTML files  
(as opposed to web applications). Being the author of Nevow I didn't  
want to dis HTMLTemplate, but Nevow really can do much, much more.

Nevow's templates are, in my opinion, even cleaner. The original goal  
of both Woven and Nevow templates was to remove all view logic from  
the template and put logic where logic belongs -- as view logic in  
Python. This doesn't mean that your "controller" is rendering the  
views, but it does mean that rather than inventing a new mini- 
language, Python is used to manipulate an intermediate template  
format (a DOM). Woven used the W3C DOM, which turned out to be  
cumbersome and heavyweight, so Nevow uses a custom document object  
model called "stan". Stan is made up of Python lists, strings, and  
instances of nevow.stan.Tag (Actually, the stan dom can contain any  
Python object as long as a flattener function is registered for the  
type). The view logic consists of manipulating this DOM in pure  
python code. You do things that you would expect -- perform tests  
against certain conditions and return one or another node depending  
on the result, loop over things copying a node and applying one piece  
of data to that node (that node then gets rendered by trampolining it  
back up to the main render loop).

In practice it works out very well, with ultra-clean templates marked  
up in strategic places and pure Python code which is very short and  
easy to read. To address concerns about how convenient it is in the  
long run, many of the common things one might do, like looping over a  
list of data and applying a node to each in turn or filling template  
slots with the values provided in a Python dictionary, are provided  
as default renderers out of the box. You don't have to write any code  
to get them. But they are provided as normal renderers, just like you  
would write. There is no template language which is fixed in stone  
and you're screwed if it doesn't do what you need it to do. If you  
find that things don't work quite the way you want them to, write  
your own renderer. It's easily extensible by design.

One non-obvious thing about this approach is that it becomes falling- 
off-a-log easy to render recursive structures. The frustration that  
lead to the approach was the experience of trying to render a  
recursive tree in ZPT -- what was I going to do, repeat the skin for  
each level of possible depth? What about infinitely deep trees? I  
ended up rendering that portion of the template using string  
concatenation in Python, and at that point all the advantages of ZPT  
had been lost. Nevow avoids this problem by giving the Python code  
the ability to manipulate the template abstractly, allowing natural  
expression of recursion (it's expressed as tail-recursion -- a  
function returns an object which will invoke the same function, with  
a different node).

So. That's what Nevow templates are about.

Donovan