Template Toolkit does everything you're asking for. What makes you think it won't work for you?
For example, the way how to produce tables out of
arrays. If I understood the examples correctly,
Template::Toolkit requires you to loop
over the array and append the code to be generated
to a special variable OUT. Since the majority
of my generated code happens inside a loop over the
data, I will end up generating 90% of the result
by just sending string to OUT; from the
viewpoint of readability certainly not something
which is a "template" anymore.
Actually, after a first glance, I meanwhile found that Text::Template::Simple and Text::ScriptTemplate could do what I want, so I will give them a try.
--
Ronald Fischer <ynnor@mm.st>
| [reply] [d/l] [select] |
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] |