[erlang-questions] Thoughts on EHE - the PHP killer

[Tim Watson]

On 19 February 2012 20:17, Matti Oinas <matti.oinas@REDACTED> wrote:
> On 02/19/2012 09:29 PM, Tim Watson wrote:
>
> That is true that you want to keep view separated but that is where django
> and others fail. View still contains code like
>
> {%  for  match  in  matches  %}
>    <div  style="background-color:
>        {%  ifchanged  match.ballot_id  %}
>            {%  cycle  "red"  "blue"  %}
>        {%  else  %}
>            grey
>        {%  endifchanged  %}
>    ">{{  match  }}</div>
> {%  endfor  %}
>
>
> That is equally ugly with embedded code and it contains logic. Even worse is
> that it added one extra language but still failed to separate logic from the
> view.
>

At least it is *presentation logic* and I could argue this both ways.
I agree that code isn't particularly elegant, but at least it is
specifically 'about' the rendering.

> Enlive on the other hand uses plain HTML templates which are transformed
> with the help of CSS selectors. There is no logic in HTML template, only
> plain old HTML. Tranformation code defines what elements will be left and
> what elements contains what information.
>
> http://cleancode.se/2011/01/04/getting-started-with-moustache-and-enlive.html
>
> Now we have separated the view from logic and it is really simple to change
> templates. That is a library that I would like to see written in erlang.

Yes I agree this is a far cleaner approach, and you will see that it
is very similar to what I proposed to Joe in a previous message on
this thread, although at the time I hadn't bothered to look at enlive
in any detail. Having spent a little time looking at enlive, I think
the approach is very neat and that it would be relatively easy to do
this in Erlang, although you'll need a 'non-strict' parser such as
https://github.com/massemanet/trane and of course the supporting
libraries for generating/munging HTML content using a nice API.