Quantcast
Channel: MindTouch Developer Blog » geek
Viewing all articles
Browse latest Browse all 10

Templating: Everything old is new again

0
0

I’ve hated mixing presentation with logic before it was cool and it’s always bothered me that for the last couple of years templating engines have steered primarily in the direction of native languages mixed 0with markup (erb, razor, ejs, etc.). However, #jsconf has given me some hope that separation of concerns is making a comeback.

<?php /* inject content here */ ?>

In the early days of the web, code was just emitting HTML as a side-effect of execution. The complete impossibility of managing the presentation layer with this approach spawned a hundred hand-rolled substitution/templating engines. I wrote at least 3 myself. PHP can be thought of as a direct descendant of these early templating engines, creating a syntax that natively intertwined code and markup.

<xsl:template match=”what-does-this-do”>

With the rise of XML, transformation of content into presentation took the form of XSLT. This was true separation of presentation and logic. However, XSLT, being a functional language, was unlike any other templating language  and authoring certainly was not designer friendly. The foreign syntax combined with requiring XHTML output and slow emergence of performant implementations kept XSLT from ever gaining mainstream acceptance.

$.template( “content”, “<h1>${Title}</h1>” );

Meanwhile XML and XHTML, at least partially driven by the configuration monsters being spawned in java enterprise land, lost popularity and developers turned towards simpler, closer to the metal templating approaches once again. Of these Ruby on Rails was clearly the resurgence leader. Using the MVC pattern, templating had much better business logic and presentation separation, but most templating engines did end up embedding Ruby in markup in some fashion or another. MVC frameworks for virtually all other runtime environments followed suit, eventually leading to templates with embedded javascript as the transformation engine on both client and server.

weld(document.querySelector(‘.content’), content)

This last development would seem rather counter to the otherwise popular unobtrusive javascript movement. Fortunately #jsconf showed at least two new templating engines with unobtrusive binding. While backbone.js and knockout.js (among others) are binding engines, they still litter the mark-up with enough javascript constructs to be  designer unfriendly. Enter weld.io and the (as yet unreleased) batman.js, two binding engines that modify plain-old HTML without any binding specific markup in the HTML:

<!DOCTYPE html>
<html>
    <head>
    </head>
    <body>
      <ul class='contacts'>
        <li class='contact'>
          <span class='name'>My Name</span>
          <p class='title'>Leet Developer</p>
        </li>
      </ul>
      <script src="lib/weld.js" type="text/javascript" charset="utf-8"></script>
      <script type="text/javascript" charset="utf-8">
var data = [{ name: 'hij1nx',  title : 'code slayer' },
            { name: 'tmpvar', title : 'code pimp' }];
weld(document.querySelector('.contact'), data);
      </script>
    </body>
</html>

wiki.template(“where do we go from here?”)

At MindTouch, we’ve had a more complex of story of separation of presentation and logic. At the application level, we’re a pure abstraction, where everything is available as application data via our REST APIs and is rendered into human/browser friendly HTML via a relatively thin PHP presentation layer. However, since our focus is on content editing and management, the edit content is fully formed HTML, which can include embedded DekiScript for HTML generation. At this time, DekiScript follows the common markup+code paradigm, as it is the simplest concept for non-programmers trying to add dynamic concepts.

So what does the future hold for templating at MindTouch? We have a considerable investment in our PHP presentation layer, but with the power of client-side javascript increasing steadily, the reliance on server-side transformation is likely to diminish with unobtrusive client-side templating techniques taking the lead. How this might influence the way we use DekiScript in page content is an unknown, but we’re exploring various approaches and would love to hear from the community how they would like DekiScript content generation, manipulation and templating to evolve.


Viewing all articles
Browse latest Browse all 10

Latest Images

Trending Articles





Latest Images