Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Phred (5358)

Phred
  fredNO@SPAMtaperfriendlymusic.org
http://www.redhotpenguin.com/

Fred is a Perl and PostgreSQL geek. He has made some very small contributions to a few cpan modules and mod_perl.

Journal of Phred (5358)

Wednesday June 06, 2007
04:37 PM

Down with templating languages

[ #33451 ]

Last night I was going to blog about the how the second system is the inherently dangerous, according to Frederick P. Brooks. As I researched it though, I came across Greenspun's Tenth Rule, which was an interesting read. In short, it says that any sufficiently complicated C or Fortran program contains a buggy implementation of Common Lisp.

It's taken me a few hours for this material to coalesce in my brain, but it seems like templating languages suffer from this same fate. I don't want a lot from templating languages. I want to be able to take some data that my application has generated, throw it at a template, and have it do what I expect.

When I started out with Mason many moons ago, it did exactly that. It was friggin' great. But Mason has all these hooks and cool features which can be (and often are) abused by programmers spending lots of time trying to save themselves future work by implementing shortcuts. Eventually, a fair amount of work goes into debugging these shortcuts, and it's evident that any expected economies of scale are falsehoods due to the fact that the maintenance cost for those shortcuts becomes overwhelming. Mason::Strict anyone??

So later on I started using Template Toolkit. I thought "This is great, I can throw objects at templates and it just works." Then I started working with more experienced template toolkit users, who knew it well enough that they were able to use it as a programming language, not just a templating language. Therein lay the danger. I managed to generate all sorts of esoteric runtime errors due to the fact that my macros didn't have the correct syntax, or some other crap that perl usually catches at compile time (and tells me the line number where the error is, instead of the package).

Along the way I used HTML::Template, which was nice also, but it was too strict for my liking. I couldn't throw objects at it, I had to serialize the objects into hashes. And I had to consult the docs to perform rudimentary operations such as loops, which I had committed to memory from perl.

So here I present to you Moyer's Eleventh Rule of Templating Languages. "Any sufficiently complicated templating language contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Perl". Take it for what it is worth, preferably with a large grain of salt. Most templating languages aren't perfect, and neither am I :)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Part of me wants to object, but part of me totally agrees.

    This is indeed why I'm pretty vocal against newbies creating their own templating language. They all start out "simple", and then slowly add variables (of course), and then decision and iteration. And once you have state/decision/iteration, you have turing completeness, and you start treating the templating language like a programming language, and it's all downhill from there.

    One of the things I like about Template Toolkit though is that it at le

    --
    • Randal L. Schwartz
    • Stonehenge
    • Is really using something like TT2 for "programmy" things so wrong?

      I have abused TT2 to develop whole websites where there's a simple Apache module that can load the base template and pass it an object which can fetch records out of the database as hashes.

      The great thing about this is that people who don't think of themselves as being able to program are doing clever things with loops, and writing conditional logic. Of course you end up with something that might not be as neat as if it used a MVC architectu
      • I don't think he was advocating that getting "programmy" with TT is wrong. He does advocate that TT has a ceiling where the "programmy" stuff gets hard and that is his signal to take a step back and look at what he is doing and how he is doing it.
      • Yes, it really is dangerous to write anything significant in the TT language. The problem is, as Fred pointed out, TT's language sucks at error messages and catching mistakes when compared to Perl. Perl gives good diagnostics, has a debugger and profiler, has strict and warnings, has perltidy, etc. TT has none of these things. Perl is also a lot more efficient in most cases.

        I think the TT language is great, as long as you stick to using it for templating tasks: put this here, loop through these. Any

    • I had a simple templating language for a year or so.

      I think when I hit the need for conditionals I realised I was heading for trouble and scrapped it for TT2.

      Lately, however, I've been trying desperately to resist writing Template::Tiny (minimalistic version of Template Toolkit) :)

      Of course, for the really simple templating language I just use...

      $text =~ s/\[\%\s*(\w+)\s*\%\]/$hash{$1}/ foreach 1 .. 10;

      or variations :)
  • The reason I generally dislike template systems like Template Toolkit, is that they have their own invented programming language, reimplementing programming constructs that are already implemented by the Perl language. It's kind of like Esperanto (I don't want to start a troll), I just personally feel it's unnatural.

    On the other hand, it's important to separate the template from the business logic, and the template often has to be simple enough for non-programmers to use.

    So maybe you're right. Let's get r

  • Templates are a nice concept, and I don't mind putting some logic in them, but, not too much.

    So, how much is too much? Well, this much: a templating system may embed values of variables, apply filters to them (for example HTML escaping), provide simple conditionals, include other templates. And that's about it.

    A templating system should not provide ways to connect to a database or to invoke SQL. Your controlling program should already have taken care of that.

    The way I would allow directly fetching data from
    • A templating system should not provide ways to connect to a database or to invoke SQL.

      That would have fixed PHP, back in the day.