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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Mixed reactions (Score:2)
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
Re: (Score:2)
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
Re: (Score:1)
Re: (Score:1)
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
Re: (Score:1)
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
or variations
that's why I prefer Mason (Score:1)
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
You can go this far, but no further... (Score:2)
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
Re: (Score:1)
That would have fixed PHP, back in the day.
Re: (Score:2)