

Your templating engine sucks and everything you've ever written is spaghetti code - nnq
http://www.workingsoftware.com.au/page/Your_templating_engine_sucks_and_everything_you_have_ever_written_is_spaghetti_code_yes_you
An interesting, simpler and more designer-friendly approach to templating.
======
dkersten
This is why I love Enlive[1], Enfocus[2] and Kioo[3] (and Enliven[4] is
looking awesome too!).

Your logic stays in your code, the _templates_ are snippets of pure HTML.
Dynamic content is generated by manipulating and composing the snippets in
code. Snippets can be defined in one large HTML file or many files - up to
you. The code uses CSS selectors to choose which parts of the HTML to use and
transform.

For example, lets say I have a blog application:

    
    
        <body>
            <div>Welcome to my Blog</div>
            <div id="posts">
                <div class="post">
                    <div class="title">My post</div>
                    <div class="content">Post content here</div>
                    <div class="comments">
                        <div class="comment">A comment</div>
                    </div>
                </div>
            </div>
        </body>
    

Then my code might look something like this:

    
    
        (enlive/defsnippet comment-snippet "myfile.html"
          [:.comments]
          [comments]
          [:.comment] (enlive/clone-for [comment comments
                        (enlivecontent comment))
    
        (enlive/defsnippet post-snippet "myfile.html"
          [:#posts]
          [posts]
          [:.post] (enlive/clone-for [{:keys [title content comments} posts]
                     [:.title]    (enlive/content title)
                     [:.content]  (enlive/content content)
                     [:.comments] (comment-snippet comments)))
    

That is, parts of snippets are selected and transformed in some way (changing
the content, adding/removing css classes or styles, setting attributes,
prepending or appending content, wrapping or unwrapping tags, duplicating for
each element in a list, etc). This lets you write your page elements as mocked
up snippets with dummy data and then merge them together, fill in content,
dynamically update attributes and classes all without putting any logic into
the HTML.

This also makes it very designer friendly because they can work in pure HTML
and CSS without worrying about templating - they only need to make sure to
follow your basic structure outline (ie making sure your selectors match the
right thing).

[1] [https://github.com/cgrand/enlive](https://github.com/cgrand/enlive)

[2]
[https://github.com/ckirkendall/enfocus](https://github.com/ckirkendall/enfocus)

[3] [https://github.com/ckirkendall/kioo](https://github.com/ckirkendall/kioo)

[4] [https://github.com/cgrand/enliven](https://github.com/cgrand/enliven)

~~~
nnq
Nice, didn't know about all that happening in the Clojure universe. The scary
part is that now your view code is tied to the structure of the HTML. The
logic gets brought up in the code, where it belongs, but so does a lot of
markup structure knowledge. Seems like an even worse outcome. Maybe it isn't,
but I've never tried the approach on any real project.

...anyway, the thread died as this is never really a hot topic, people just
use whatever templating language is "default" in their fav framework and don't
like to overthink this, I guess :)

~~~
dkersten
_The scary part is that now your view code is tied to the structure of the
HTML._

I haven't really found this to be the case as long as you only use id's and
classes as selectors. That is, in my example, I don't care what a post looks
like, as long as it has a _.title_ , _.content_ and _.comments_. In large
projects, I use naming conventions to designate certain classes as data
elements (ie elements whose content will be overwritten with data), some as
non-data content (ie elements which will be duplicated), some as page elements
(containers for other elements) etc

The reality is that all templating has logic and HTML structure married in
some way (in most templating systems its the reverse as the code is in the
HTML), but I find that as long as you don't need complex selectors that rely
on which span is contained in what div or whatever, then I don't care about
the structure - I only care that certain id's and classes (sometimes sets of
classes) refer to a snippet I wish to modify. At the end of the day, in a real
application, there is likely always going to be a little coupling, but I
haven't noticed it to be a big deal (at least, not yet).

I also find that in large applications, you may have a lot of self-contained
reusable components (dialogs, widgets, etc). In these cases, I don't mind
having the code and HTML coupled, as long as the components can be styled to
suit my application externally (ie purely with CSS). For example, in an app
I'm building right now, I have a table widget - the code and HTML are tightly
coupled, but I can reuse the widget without touching either because I can
style it using CSS. This is obviously only the case for self contained widgets
that don't need to be changed and not general UI components.

Final thoughts: my current application is written with Om (one of the
ClojureScript libraries for using React), which treats the rendering as a
function of the state: _f(state) - > UI_

I use Kioo to construct my components in template-free HTML and my
ClojureScript code manipulates it based on the data. The logic is really
simple - its a one-way system: data -> logic -> template (raw HTML) -> page
(processed HTML)

