

The genius of Enlive as a template system - lkrubner
https://github.com/swannodette/enlive-tutorial

======
stevencorona
I dislike PHP, but why did they purposely make the PHP example as horrible as
possible? Like, they skipped short-tags, wrapped closing PHP tags, didn't use
non-brace syntax (which is useful in templates), and didn't use a foreach loop
like they did in the Python example.

    
    
        <?php
        for($i = 0; $i < $len; $i++) {
        ?><p>Foo <?echo $i?></p><?
        }
        ?>
    

vs

    
    
        <? foreach($foo as $i): ?>
          <p>Foo <?= $i ?> </p>
        <? endforeach ?>
    

I understand you want to sell your project, but don't make the examples
deceiving.

~~~
godDLL
I don't… I don't see much difference.

    
    
        ~$ python
        >>> A = "<?php for($i = 0; $i < $len; $i++) { ?><p>Foo <?echo $i?></p><? } ?>"
        >>> B = "<? foreach($foo as $i): ?> <p>Foo <?= $i ?> </p> <? endforeach ?>"
        >>> L = [A,B]; import re
        >>> map(len, L)
        [68, 65]
        >>> map(lambda x: len([s for s in x if re.match('\w', s)]), L)
        [23, 29]
    

Isn't it about the same amount of alphanum vs noise? About the same length
too.

I'm not sure B is more readable than A in any way. Maybe more 'idiomatic',
meaning 'way humans think'; but I'm not sure about that.

~~~
chc
B is just a bit more cleanly organized. Somewhat like the difference between
code that uses sensible indentation and code that uses deceptive indentation —
they both look statistically similar, but the organization helps us read it.

------
lrenn
Unfortunately, it seems the author doesn't have time to keep up with it's
popularity. The code hasn't been updated in months (other than the "lazy
fix"). There are 23 open issues, many over a year old.

<https://github.com/cgrand/enlive/issues?state=open>

I got hit by a bug the other day (it assumes http resources are UTF8), and
even though fixes are available, none have been merged in.

See also "Is Enlive Alive?"

[https://groups.google.com/forum/?fromgroups=#!topic/enlive-c...](https://groups.google.com/forum/?fromgroups=#!topic/enlive-
clj/UwEjTr-u48Q)

Having said that, I still think Enlive is awesome. I just which development
was more active. Take a look at the network graph and you'll see people fixing
a lot of issues on their own branches.

------
ianb
Lots of these kinds of push templates have existed, none of them seem to have
legs. I think they seem elegant, but mixing logic and HTML is actually just a
great way to do things. When you want to change something you see in the HTML
– be it dynamic or static – then you always know where to look. And when you
come back to some code 6 months later you'll really appreciate the simplicity.

Even in Javascript traditional templates have seen a surge in popularity, even
though push-style templates have always been the more natural way to operate
(in the case of Javascript, modifying the DOM directly).

------
d0m
I'll give it a try in a personal project but I hardly see myself asking my
designers to use this template system.. Call me grumpy or old, but when
working in a team, I like to keep template files as close to html as possible.
It's so much easier to use a technology that everyone understands or to hire
externally to speed things up.

~~~
lukev
That's sort of the point, though: the templates are _completely_ HTML. There's
nothing else in them at all. Your designers can write straight up HTML and not
worry about templating at all.

Of course, then it's on you as a developer to use Enlive to replace whatever
stub/sample elements are present in the HTML with real data, so it's not an
entirely free lunch.

~~~
simonw
That doesn't fit my experience of how designers work with templates. The
problem with this style of template system is that it's very tightly coupled
to the HTML of the template. If a designer wants to e.g. change the class on
an element (because they want to use a CSS class from bootstrap) they can't
without worrying about what's in the clojure code. It becomes almost
impossible for them to make anything more than a trivial change without a full
understanding of the code that will be manipulating their templates.

~~~
pmjordan
Hmm, I've only used enlive on a small project, and that was quite a while back
(I haven't done any webdev lately) and I generally ended up marking my
templated elements with special ids or classes. Artificial example coming up:

    
    
      <ul>
        <li class="item-template">
          <a href="#" class="item-link-template"><strong class="item-caption-template">Some dummy caption</strong></a>
            &mdash; <span class="item-description-standin">Some dummy description</span>
        </li>
      </ul>
    

The _item-template_ marks the outer-most element to use for repetition. The
_item-link-template_ can be used to set the href attribute. The contents of
the tag marked with _item-caption-template_ will be replaced with whatever
content. The _item-description-standin_ gets replaced with content outright.
If you, say, want to remove the <strong> tags around the caption, just move
the templating class to the parent item.

    
    
      <ul>
        <li class="item-template">
          <a href="#" class="item-link-template item-caption-template">Some dummy caption</a>
            &mdash; <span class="item-description-standin">Some dummy description</span>
        </li>
      </ul>
    

If you come up with some conventions, e.g. "-standin" gets replaced
completely, whereas "-template" just gets transformed; each marker is only
used for one purpose (don't conflate the link and the caption marker in the
latter example), it works rather well, probably better than any other
templating system I've used.

My only gripes with Enlive at the time were that it was overly macro-heavy
(def'ing everything as opposed to returning values), and loading templates was
quite slow, which made on-the-fly modifications to HTML generated elsewhere
ineffecient. I suspect both are better these days, as it was still heavily in
development at the time.

------
emeidi
This is not gonna fly. It's replacing a quick, but dirty solution (PHP-style
templating), but in turn makes it too complex to maintain and very hard to
understand.

I have never understood why someone would another abstraction layer to
templating.

------
draegtun
Seen lots of template systems use this "Push style" before -
<http://www.perlmonks.org/?node_id=674225>

