use strict;
use warnings;
use Template;
my $template = Template->new({
INCLUDE_PATH => '.',
EVAL_PERL => 1,
}) || die $!;
my $foo = foo(3,5);
my @s = ('this', 'that');
$template->process("tpl.txt", {foo => $foo, s => \@s}) || die $templat
+e->error();
sub foo { $_[0]+$_[1] }
the template file
This is some line.
This is a line with some expression: [% foo %]
[% FOREACH l = s %]
This is [% l %] line
[% END %]
This is the end
btw. It's up to you to make your code readable. If you have arrays, you'll have to cycle through its elements. Template is not to blame. | [reply]
[d/l]
[select] |
It's up to you to make your code readable. If you have arrays, you'll have to cycle through its elements. Template is not to blame.
CORRECTION: When I posted below, I stupidly did not
refer to Template::Toolkit, but to Text::Template.
My comments regarding Template::Toolkit are at the
end of this posting.
Although I can understand your argument, my view differs here. As for the syntax, I am well aware of the readability problems. Text::ScriptTemplate is modelled to the way JSP, ASP and similar tools work, and this means it shares their weaknesses (blocking intendation of the control structure is intermixed with literal code which can not be intended, and you really have to get used to construct such as <% if (....) { %>. On the other hand, many people *are* familiar with this style, simply because it is used in several other products, so at least it will be easy to grasp to new members of the project. In particular, it means that the template can be modified by people who are not familiar with the code, or with Perl programming in general. This might be a benefit in the future.
As for the usage of the OUT variable in Text::Template, I certainly don't want to blame this module. It is a perfectly logical solution; only that I see no advantage in writing a small "template frame", and inside it a triple-nested loop putting together all the output data and stuffing it into OUT. If I would do this, I would probably write the whole thing in Perl and not use a separate text template at all.
In this case, however, the requirement of the task is to use a template file, and inside it to have as simple Perl code as possible. Having loops for processing of tables is OK, and also the use of conditionals, but otherwise it should ideally be just data references and "plain text". I say
"ideally" because I could do it differently, but Text::ScriptTemplate looks so close to what is required, that I think it is a good idea to go with it.
Actually, I had also given a second look to Template::Toolkit and as for the syntax, it seems to be even better suitable for our project. Its disadvantage is that it contains a compiled part, which makes it more painful to use for our application (which - again: ideally - should use external modules only if they are 100% Perl and platform independent).
--
Ronald Fischer <ynnor@mm.st>
| [reply]
[d/l] |
Actually, I had also given a second look to Template::Toolkit and as for the syntax, it seems to be even better suitable for our project. Its disadvantage is that it contains a compiled part, which makes it more painful to use for our application (which - again: ideally - should use external modules only if they are 100% Perl and platform independent).
The only binary module is Template::Stash::XS. You do not have to use it as it has the same functionality as Template::Stash which is pure perl implementation. The template toolkit chooses automatically the fastest available implementation so your do not have to change your code and templates.
Template::Toolkit is really excellent. I have saved my life on lot of occasions. It is well maintained and it is integrated in a lot off frameworks that need template engine.
| [reply] |