ivan <[EMAIL PROTECTED]> writes:
> On Tue, May 22, 2001 at 11:52:31AM +0200, Jonas Liljegren wrote:
> > ivan <[EMAIL PROTECTED]> writes:
> >
> > > > > > > Is TT2 a "little language" or "eval" templating system?
> > > > > >
> > > > > > It can be anything you want it to be. ;-)
> > > > >
> > > > > That's a silly answer.
> > > >
> > > > There are two methods to embed perl code in the template.
> > >
> > > But - and this is the important bit - can you do the *reverse* - can you
> > > embed TEMPLATE in perl code? The equivalent of (for example) Mason's:
> > >
> > > % foreach $option ( @options ) {
> > > <OPTION><% $option %>
> > > % }
> >
> > Yes. TT is flexible. I can't hope to imagine all the ways to do it.
> > But you could process a template from perl:
>
> > [% BLOCK optrow %]
> > <option>[% myopt %]
> > [% END %]
> >
> > [% PERL %]
> > foreach my $option ( 'a', 'b', 'c' ) {
> > print $context->process('optrow', { myopt => $option });
> > }
> > [% END %]
>
> This is no better than not using a templating system.
For this case, yes. But the prefered way is to separate the templates
form the program code. You would put the logic in a spearate program
and let the template be as simple as possible.
> > There are many more ways. But the *prefered* way would be to just do:
> >
> > [% FOREACH myopt = [ 'a', 'b', 'c' ] %]
> > <option>$myopt
> > [% END %]
>
> Again - exactly why I prefer "eval" templating systems. "little language"
> templating systems re-invent loop and conditional constructs when Perl has
> perfectly adequate constructs for these things.
Templates are not the same thing as programming languages. These
constructs are especially constructed for use in templates. They are
in that context more elegant than an ordinary perl loop.
> > > Note that if eval()ed as stand-alone Perl, both of the % sections would
> > > generate syntax erros.
> >
> > Speaking of that... You CAN do it almost exactly like your example,
> > with the RAWPERL option. (Especially if you replace that set() by
> > binding $option.) But this is a bit slower in execution than above:
> >
> > [% RAWPERL %] foreach $option ( 'a', 'b', 'c' ) {
> > $stash->set( myopt => $option );
> > [% END %]
> > <option>$myopt
> > [% RAWPERL %] } [% END %]
>
> You are incorrect. According to the TT documentation at
> http://www.template-toolkit.org/docs/plain/Manual/Directives.html, RAWPERL
> blocks are eval()'ed into subroutine references. The above would generate
> syntax errors.
No. It do work. I wrote a test program to check my syntax:
#!/usr/bin/perl -w
use strict;
use Template;
print "Content-type: text/html\n\n";
my $template = Template->new( EVAL_PERL => 1,
PRE_CHOMP => 1,
INTERPOLATE => 1);
#$Template::Parser::DEBUG = 1;
#$Template::Directive::PRETTY = 1;
$template->process(\*DATA, { place => 'world'})
or die "Template process failed: ", $template->error(), "\n";
__DATA__
<h1>Hello $place!</h1>
[% RAWPERL %] foreach my $option ( 'a', 'b', 'c' ) {
$stash->set( myopt => $option );
[% END %]
<option>$myopt
[% RAWPERL %] } [% END %]
And the Output is:
Content-type: text/html
<h1>Hello world!</h1>
<option>a
<option>b
<option>c
The template is converted into a perl sub, like this:
sub {
my $context = shift || die "template sub called without context\n";
my $stash = $context->stash;
my $output = '';
my $error;
eval { BLOCK: {
$output .= "\n<h1>Hello ";
$output .= $stash->get('place');
$output .= "!</h1>\n";
# RAWPERL
#line 1 "RAWPERL block (starting line 5)"
foreach my $option ( 'a', 'b', 'c' ) {
$stash->set( myopt => $option );
$output .= "\n <option>";
$output .= $stash->get('myopt');
# RAWPERL
#line 1 "RAWPERL block (starting line 11)"
}
$output .= "\n";
} };
if ($@) {
$error = $context->catch($@, \$output);
die $error unless $error->type eq 'return';
}
return $output;
}
> > Using these options. I guess you could
> > ultimately write your example like this:
> >
> > % foreach $option ( @options ) {
> > <OPTION><% $option %>
> > % }
>
> No, you could not. The TT parser is *backwards* for this sort of thing
> and expects all Perl sections to be valid as self-contained Perl. You are
> completely missing the distinction that makes the above possible in Mason,
> and impossible in Template Toolkit.
As I have proved above. It is both possible and easy!
Not as clean as the Mason version. But for me, those inline (eval)
things are backwards. It's just like turning the perl program inside
out. Quoting the code instead of the print functions. Just like
PHP. You could just do a "print <<HERE" instead and inline all the code
with the @{[CODE]} syntax, already existing in perl.
That sort of thing solves the 'first' problem, giving you something a
little more convenient than HERE blocks. TT2 does much, much more.
> > > > > Personally, I favor the "eval" templating systems
> > > >
> > > > Why?
> >
>
> Umm, that was *YOU* asking *ME* why I favor the "eval" templating systems.
Yes. And I think you have answerd me.
> > Most of the time it's better to separate
> >
> > - data
> > - configuration
> > - logic
> > - presentation
>
> All templating systems allow you to do this.
I guess I can understand that you can prefere that "eval" style. But
that do mean that you mix program code with the presentation markup.
% foreach $option ( @options ) {
<OPTION><% $option %>
% }
This is an example of mixing them. For this case, it's not that bad.
But for more complicated cases, you would have to create custom subs
or prepare the data in an initialization sub.
TT is helping you with that separation. Making it less messy. It's
specially adapted for templating tasks. But it's at the same time
fully integrated with Perl.
And, yes. I'm religious about it. Please don't let my fanatism turn
you away from TT. Try it out and write to the list:
http://www.tt2.org/info.html#lists
--
/ Jonas - http://jonas.liljegren.org/myself/en/index.html
