RFC: template engine [ was: Re: Implementing tables - advice wanted ]

Wed Jun 14 16:47:59 CEST 2006

> Romain Lenglet wrote:
>
> just a reference:
> Enforcing Strict Model-View Separation in Template Engines
> http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf

Excellent reference paper, thanks.  I think all could benefit from  
reading this as well as other info at http://www.stringtemplate.org/

A good summary as it relates to this thread...from http:// 
www.stringtemplate.org/doc/doc.tml
<snip>
After examining hundreds of template files that I created over years  
of jGuru.com (and now in ANTLR v3) development, I found that I needed  
only the following four basic canonical operations (with some  
variations):

     * attribute reference; e.g., $phoneNumber$
     * template reference (like #include or macro expansion); e.g.,  
$searchbox()$
     * conditional include of subtemplate (an IF statement); e.g., $if 
(title)$<title>$title$</title>$endif$
     * template application to list of attributes; e.g., $names:bold()$
</snip>

Indeed, these four characteristics seem to be all we need and is in  
line with mine and others' intuition that a template engine should  
_not_ be a Turing complete language.
Unfortunately, StringTemplate has no C port...only Java, Python and  
C# variants..
It does seem that building a clean-room erlang implementation of  
StringTemplate would be easy for someone handy with lex and parse  
tools, hence bypassing an antlr dependancy and implementing entirely  
in erlang.
 From there, we only need some basic additions to yaws to pull it all  
together.

Of course, if Joe's existing template engine embodies the same  
principals as StringTemplate, then that seems worth plugging into  
yaws as well.
To be fair to Claes, yaws already does some of this...variable  
bindings, yssi, etc..but it comes together as separate utils, not a  
cohesive template strategy.

ke han

On Jun 14, 2006, at 4:17 PM, Gaspar Chilingarov wrote:

> Romain Lenglet wrote:
>
> just a reference:
> Enforcing Strict Model-View Separation in Template Engines.
> http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
>
>> [....]
>> I would personally avoid any imperative / non-declarative
>> construct in a template language.
>> Tons of template languages exist for PHP, etc. so one should at
>> least look at them and reuse ideas from them.
>> Many existing usable template engines / languages end up having
>> the same characteristics / features:
>>
>> - they usually apply the MVC pattern,
>>
>> - in views, the pattern language allow to identify placeholders
>> for values (strings) set by the controller (by the code), and
>> allow to identify / markup blocks of text that are optional or
>> that can be repeated, as controlled by the controller;
>>
>> - some languages allow to recursively identify blocks inside
>> blocks in views;
>>
>> - the only information shared between a view (a template) and a
>> controller (Erlang code) is: the names of value placeholders,
>> and the names and structures (hierarchies) of
>> optional/repeatable blocks.
>>
>
>
>
>> The view language is usually completely declarative. If you need
>> to do a loop to repeat a block, you should do it in the code (in
>> the controller), not by defining a "FOREACH" construct in the
>> template language (in the view).
>>
>
> hm, this sounds good - I should think about such model.
>
>
>>
>> A good, simple template language that can directly be used in an
>> Erlang template engine in that of PHP Pear:
>> http://pear.php.net/manual/en/package.html.html-template-it.intro.php
>>
>> For example, using this syntax, one view could be:
>>
>> <html>
>>  <table border>
>> <!-- BEGIN row -->
>>   <tr>
>> <!-- BEGIN cell -->
>>    <td>
>>     {DATA}
>>    </td>
>> <!-- END cell -->
>>   </tr>
>> <!-- END row -->
>>  </table>
>> </html>
>>
>> The advantage of that syntax is that it allows most of the time
>> to edit a template as HTML using any existing visual editor:
>> nvu, dreamweaver, etc. This simplifies the design of templates
>> by non-programmers. No loops, no programming logic in views.
>>
>>
>> Then, the template engine could allow a controller in Erlang to
>> process a template like:
>>
>> engine:parse_template("foo.tpl.html",
>>   [{block, row,
>>      [{block, cell, [{variable, DATA, "hello"}]},
>>       {block, cell, [{variable, DATA, "world"}]}]}])
>>
>> which would return a string containing the whole parsed template.
>>
>
>> PHP Pear also allows to maintain a cache of pre-parsed templates,
>> to improve performance. This should be provided also by an
>> Erlang template engine.
>>
>
> this is quite simple to do in erlang - just hang aroung caching  
> process
> - one thing which you can not have done in php and apache (monitord is
> somehow working solution).
>
>
> -- 
> Gaspar Chilingarov
>
> System Administrator,
> Network security consulting
>
> t +37493 419763 (mob)
> i 63174784
> e nm@REDACTED