http://www.perlmonks.org?node_id=1193462

Why learn a whole new language for templating when you already know a perfectly good one? This isn't the first module that allows you to embed Perl in your templates, but it's yet another one.

use Types::Standard -types; use Template::Compiled; my $template = Template::Compiled->new( signature => [ name => Str, age => Int->plus_coercions(Num, sub { int $_ } ), ], template => '<p>Hi <?= $name ?>. You are <?= $age ?> years old.</p +>', escape => 'html', ); # The number will be rounded. # The ampersand will be escaped properly. # print $template->( name => 'Alice & Bob', age => 45.1 );

Template::Compiled on MetaCPAN.

Replies are listed 'Best First'.
Re: Because CPAN Needs More Templating Modules
by Discipulus (Monsignor) on Jun 24, 2017 at 22:01 UTC
    thanks tobyink for another good piece of software,

    but you can kidly expand a bit which kind of feaures you put in your yet another template system?

    Recently a meditation about templates took place and speed was stressed. I read that being at the end perl's coderef your templates must be fast: you tried some bench with big templates too?

    You say module that allows you to embed Perl in your templates but is not the tendence to extrapolate templates from source code?

    I ask such things while having still no practical experience in differences between templates usage within perl, so i'm interested in what you put more stress developping this module (having tried similar thing me too in the past, for a mailer system)

    L*

    There are no rules, there are no thumbs..
    Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

      Recently a meditation about templates took place and speed was stressed. I read that being at the end perl's coderef your templates must be fast: you tried some bench with big templates too?

      Sure. Here's a comparison with Template::Toolkit:

      use strict; use warnings; use Benchmark qw(cmpthese); use Types::Standard -types; use Template::Compiled; use Template; my $RENDER_COUNT = 1; my %data = ( name => 'Alice & Bob', age => 45.1 ); sub template_compiled { my $template = Template::Compiled->new( signature => [ name => Str, age => Int->plus_coercions(Num, q{ int $_ }), ], template => '<p>Hi <?= $name ?>. You are <?= $age ?> years old +.</p>', escape => 'html', ); my $sub = $template->sub; return $sub->(\%data) if $RENDER_COUNT == 1; $sub->(\%data) for 1 .. $RENDER_COUNT; } sub template_toolkit { my $tt = Template->new; my $template = q{[% USE Math %]<p>Hi [% name|html %]. You are [% M +ath.int(age)|html %] years old.</p>}; my $out = ''; return $tt->process(\$template, \%data, \$out) && $out if $RENDER_COUNT == 1; $out = '' || $tt->process(\$template, \%data, \$out) for 1 .. $RENDER_COUNT; } for my $i (1, 10, 100) { $RENDER_COUNT = $i; print "\$RENDER_COUNT = $RENDER_COUNT\n"; cmpthese(-1, { TemplateToolkit => \&template_toolkit, TemplateCompiled => \&template_compiled, }); print "\n"; } __END__ $RENDER_COUNT = 1 Rate TemplateCompiled TemplateToolkit TemplateCompiled 517/s -- -47% TemplateToolkit 984/s 90% -- $RENDER_COUNT = 10 Rate TemplateToolkit TemplateCompiled TemplateToolkit 93.3/s -- -76% TemplateCompiled 394/s 322% -- $RENDER_COUNT = 100 Rate TemplateToolkit TemplateCompiled TemplateToolkit 9.62/s -- -95% TemplateCompiled 204/s 2018% --

      Template::Toolkit is about twice as fast in the case where the template is used once only. If the template is compiled once and then re-used ten times, then Template::Compiled is about four times the speed. If it's used 100 times, then Template::Compiled is more than 20 times the speed.

      It's not hard to figure out which would be the winner in the case where you needed to send an HTML e-mail to 100,000 customers.

      It's also worth noting that in all these examples, Template::Compiled is doing more for you than Template::Toolkit is. For example, it is sanity checking arguments. If you do:

      $data{name} = [];

      Then Template::Toolkit will happily print:

      <p>Hi ARRAY(0x1afa178). You are 45 years old.</p>

      Template::Compiled will throw an exception because you said name is a Str.

      You say module that allows you to embed Perl in your templates but is not the tendence to extrapolate templates from source code?

      Any non-trivial template implementation will support things like conditional blocks and loop structures. Most will invent their own syntax for it, like in Template::Toolkit:

      [% IF atrisk %] Danger Will Robinson [% END %]

      Template::Compiled just allows you to use Perl in the template:

      <? if ($atrisk) { ?> Danger Will Robinson <? } ?>

      Hopefully this addresses your questions.

        Thanks tobyink,

        Your benchmarks make it clear. Also to have perl code directly into the template is a plus at least in terms of semplicity. I started programming before separation of concern was so valueted and most times I still prefere having all at glance, more if the project is little or minimal.

        What I still wonder is about the dimension of the template itself. When I asked for some bench with big templates I was not speaking about big templates systems but about big template texts.

        I mean, there is some performance degradation as the template goes bigger? You shown us a few bytes template: what happens for 10Kb 100Kb 1000kb ones?

        I dont want you show all possible benchmarks! you was so kind to share this module and to answer me, I just want to know if you have some theorethical idea about it. If I have the time I'l try to enrich the benchmark you shown.

        I suppose that your templates, being in memory coderefs, will be surely fast as perl itself, but they must add their memory footprint into the main process of the program, obviously.

        Is this the same of having the template cached? Or the caching ability of Template::Toolkit and others, acts differently? I ask this in the perspective of a persistent application.

        For completness i add that the module quoted as super fast was Text::Xslate and the thread was Best way to start a perl project

        Docs of Text::Xslate point also to a very exhaustive comparison, if bit aged, between template systems: at Sam Graham's website he used his Template::Benchmark to extrapolates results. Where your module would go?

        That said your module will be for sure a good choice for simple things, being all at glance and very perlish, and a good candidate for bigger projects, possibly persistent ones.

        Sorry if I abused of you patience and thanks you again!



        L*

        There are no rules, there are no thumbs..
        Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
Re: Because CPAN Needs More Templating Modules
by shmem (Chancellor) on Jun 25, 2017 at 18:54 UTC
    Why learn a whole new language for templating when you already know a perfectly good one?

    You're kicking in my open doors. Eventually my first meditation here was about the same - compiled templates converted into coderefs - and I've been discouraged, wrote a followup, packaged AutoReloader for my own needs, uploaded it to CPAN and moved to other things.

    It looks like if ideas are carried out by the right people, they have a better chance.

    Looking into your module. Thanks.

    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
      It looks like if ideas are carried out by the right people, they have a better chance.

      Agreed.

      Looking into your module.

      So am I. New wheels by quality people deserve a good test drive imho. Why not? They've provided quality help/code/responses in the past, and just because a wheel has been redesigned a few times, who's to say the newer design isn't more efficient/effective/durable?

      I'm good with new thoughts on old problems; sometimes projects that have been around a while have a specific focus where possibly a new one has the agility to step outside the box and implement something new that nobody has seen before.

      ++