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

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.