This is what a "template" looks like in Enlive. Enlive actually can extract HTML fragments out of a pure HTML file and manipulate them. This means designers can work in pure HTML and the coder can manipulate those HTML files at will w/o putting any code into the markup.
Well, thanks for providing a peek, although I'm still not sure I could bear that syntax. I just find it very hard to parse ("})})))", seriously?), but perhaps that gets better with age/familiarity.
The "can extract fragments from pure HTML" part certainly sounds interesting. But still I have to wonder how well that scales to complex templates. I mean, mixing logic into templates is ugly, but the alternative - completely separating the interpretation from the template - doesn't seem so rosy to me either. During a bigger re-arrangement I imagine it could become quite nasty to re-sync the new template version with what the code expects?
I assume the above "template interpretation code" was for quite a trivial thing. What would it look like for complex stuff? (70 chars of closing parentheses? ;-) )
{%for x in foo%}
<div id="cool">{{x.bar}} {{x.baz|pluralize}}</div>
{%endfor%}
It's just different flavors of line noise. At least with Emacs you have paredit to manage code structure for you, no need manually track parens/braces at all.
Not pretty in any way but I guess 15 years of familiarity play their part and I have never had a big problem with that particular concept (it just works well for me in practice).
However, to each their own. Looking forward to see how compojure adoption will play out, perhaps at some point I'll just "get it" and wonder how I ever worked without it. ;-)
