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

Gaspar Chilingarov nm@REDACTED
Wed Jun 14 10:17:12 CEST 2006

Romain Lenglet wrote:

just a reference:
Enforcing Strict Model-View Separation in Template Engines.

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

More information about the erlang-questions mailing list