See your thread from earlier this month where several Monks recommended that you use templates to separate your HTML from your Perl code.

If I really really need sinppets of HTML in my program for some reason (e.g. because I am avoiding using a JavaSCript framework on the front end), I still use Template to generate them, so the raw HTML is kept apart. In such a case you would have the code you showed in its own something.tt template file, that would be processed with output stored in a reference to a scalar variable. The technique is somewhat convoluted as you wind up with a number of template files, so naming them sensibly and storing them in a logical file structure is important, but for me it's worth it since I don't like to feel dirty.

Template can also render in-memory templates via

my $var;
my $template = Template->new;
$template->process( \'In-place [% foo %] query', { foo => 42 }, \$var 
+);
[download]

It comes with a performance penalty though as TT does not cache compiled in-memory templates by default.

UPD As 1nickt mentions, the penalty can be overcome by compiling the template explicitly:

my $tt = Template->new;
my $compiled = $tt->template( \'In-place [% foo %] query' );
$template->process( $compiled, { foo => 42 }, \$var );
[download]

TT does not cache compiled templates. This can be overcome but not easily

WAT? Caching and Compling Options in Template::Toolkit.

Hi Dallaylaen,

TT does not cache compiled templates. This can be overcome but not easily.

Just to clarify, I assume you mean that the Template Toolkit does not cache compiled templates *persistently* if they originated as a reference to a string, as you showed.

See the documentation on "Caching and Compiling Options".

You can cache compiled templates in memory explicitly without even processing them using template():

$ perl -MTemplate -wE '
my $tt = Template->new;
my $compiled = $tt->template(\"In-place [% foo %] query\n");
my $answer = 40;
$tt->process( $compiled, {foo => $answer++} ) for 0..2;
'
In-place 40 query
In-place 41 query
In-place 42 query
[download]

And of course you can cache persistently between program runs if you use the right configuration options (and use a template file or filehandle):

my $tt = Template->new(
    INCLUDE_PATH => '/some/path',
    COMPILE_DIR  => '/other/path',
    COMPILE_EXT  => '.compiled',
);

my $file = 'foo.tt';
my $data = { foo => 42 };

$tt->process( $file, $data ) or die $tt->error;
# Template will be compiled and cached at '/other/path/foo.tt.compiled
+'
# and that file will be used until '/some/path/foo.tt' changes
[download]

I'm sure you knew this, just clarifying for future readers...


The way forward always starts with a minimal test.

Have you considered using a template solution to separate your HTML/JavaScript etc from your perl code?

I have moved to templates for larger chunks of code. This particular line (and a couple of other smaller snippets of js) is part of a module in a larger project and it didn’t seem like a good use of resources to pull in another module for three lines of code. It seemed like overkill.

Does the larger project involve "larger chunks of code", of the sort you've moved to templates for? Probably.

Does the larget project, therefore, use templates? Hopefully.

If so, then using the same templating system in this module as in the larger project isn't pulling in anything new, it's just using what will already be loaded as a part of the overall project.

And, if not, I wouldn't let that stop me from maintaining a clean separation of concerns by using templates in the module anyhow. On the contrary, I'd start with templates in the module, since that appears to be where you're currently writing new code, then expand from there until all of the HTML content in the entire project is produced using templates instead of coming from mixed HTML and Perl frankencode.

There is always a TIMTOWTDI.

Consider something like illustrated in this simple but very instructive example from the friendly manual of HTML::HTML5::Builder by tobyink:

use HTML::HTML5::Builder qw[:standard JQUERY];
 
open my $fh, '<', 'inline-script.js';
 
print html(
  -lang => 'en',
  head(
    title('Test'),
    Meta(-charset => 'utf-8'),
  ),
  body(
    h1('Test'),
    p('This is a test.'),
    JQUERY(-version => '1.6.4'),
    script(-type => 'text/javascript', $fh),
  ),
);
[download]

For an example of total abuse of Plack see Re^3: How do I run a loop within a PSGI application. See also Re^3: RFC: Proofread the POD for my HTML elements module, PSGI and Plack.

Hello nysus,

Have you considered:

1) Moving here-docs to constants (or "constants" aka my variables that only your module sees)?

2) using q{ ... } for multi-line/very long strings?

3) Using sprintf + HTML::Entities/HTML::Escape as a poor man's template?

I don't think it's time to look at __DATA__ until these options are eliminated...

You know what you got there?

You got constipation

cleaner code starts by seperating data from code

Ok, you're ditching that idea because its not a lot data, ok, decision made,

its done,

but then why does a few lines of javascript include pointless junk like that load_js

and then why are you cramping about using up space?

When you go to the bathroom, do you flush the toilet and wash your hands every time or do you worry about using up water?

Surveys are a poor substitute for the fiber of experience , go write code