Regardless..., if you're actually writing code like this at all you'd benefit from taking the time learning how not to have to do such things. Separation of data from code is a good first step.

Separation of data from code is a good first step

Previously I have attempted to separate an HTML template from the functional code, admittedly not using a pre-built templating system. This was for a system that provides a business overview of KPIs to my senior management team both on demand as a webpage and as an email twice weekly. This code that was produced quite a few years ago is still operational and providing good service.

Here is an extract from the template file:

<div style="float:right">
<p class="sectionHead"><b>FHL Properties:</b></p>
<table>
<tr>
<th class="itemHead">Bookings this month:</th>
<td>%BOOK_MTH% </td>
</tr><tr>
<th class="itemHead">Previous 30 days:</th>
<td>%BOOK_PREV% </td>
</tr><tr>
<th class="itemHead">Forthcoming 30 days:</th>
<td>%BOOK_30% </td>
</tr><tr>
<th class="itemHead">Forthcoming 60 days:</th>
<td>%BOOK_60% </td>
</tr>
</table>
</div>
<hr style="clear:both">

<p class="sectionHead"><b>Progress in Property Event:</b></p>
<p class="itemHeadLarge">%EVENT_COUNT% people have registered their in
+terest</p>
<hr>

<p class="sectionHead"><b>Customer Contentment Call List:</b></p>
<p class="itemHeadLarge">There are %CALLLIST% people are on the Call L
+ist</p>
<hr>
[download]

with the %MARKUP% being substituted for the calculated values by the delivery code

    $pulse =~ s/%EMAIL_VIEW_PERCENT%/$empview/g;
    $pulse =~ s/%EMAIL_CLICK_PERCENT%/$empclick/g;
    $pulse =~ s/%EMAIL_UNSUB_PERCENT%/$empunsub/g;
    $pulse =~ s/%SHORTLIST%/$shortlist/g;
    $pulse =~ s/%CALLLIST%/$calllist/g;
[download]

In practice this is difficult to maintain as there are some 50 items of data to substitute as some KPIs have multiple values and some require pluralisation whilst other don't. From this limited experience quite some time ago, templating seems more trouble than value...or is this not what you mean?

If there is a way to simplify it which can be quickly implemented then I would certainly change my approach.

One problem I have faced in the past with this code is that the path to the template file is hard-coded to the production version so I have to remember to change this in the test environment before making changes and swap it back before releasing it back to the wild. It was done this way because the script runs from cron to provide the twice weekly emails. It will be simpler in future because fellow Monks have introduced me to use FindBin; and use lib; that will make this particular application a great deal simpler...perhaps that change alone will revise my experience of HTML templates.

some require pluralisation whilst other don't.

Have you seen Lingua::EN::Inflexion? It allows you to construct a generic pattern (a template of sorts) to handle various cases like this.

If there is a way to simplify it which can be quickly implemented then I would certainly change my approach.

It can be quickly implemented, if not quickly learnt. Because these are modules with which I am familiar I would use Template for the templating system with the Template::Plugin::Lingua::EN::Inflexion plugin which would allow for a simple loop to produce the table contents and proper pluralisation of the prose. TIMTOWTDI, of course.

#!/usr/bin/env perl 
use strict;
use warnings;

use Template;

# Set up your data
my $data = {
    table => [
        {
            head => 'Bookings this month',
            val  => 132,
        },
        {
            head => 'Previous 30 days',
            val  => 99,
        },
        {
            head => 'Forthcoming 30 days',
            val  => 150,
        },
        {
            head => 'Forthcoming 60 days',
            val  => 189,
        },
    ],
    event_count => 1,
    call_list   => 5
};

# Set up your template (easiest/commonest in an external datastore (fi
+le
# or DB)
my $template = <<EOT;
<div style="float:right">
<p class="sectionHead"><b>FHL Properties:</b></p>
<table>
[% FOR k IN table %]
<tr>
<th class="itemHead">[% k.head %]:</th>
<td>[% k.val %] </td>
</tr>
[% END %]
</table>
</div>
<hr style="clear:both">

[% USE infl = Lingua.EN.Inflexion; FILTER inflect; -%]
<p class="sectionHead"><b>Progress in Property Event:</b></p>
<p class="itemHeadLarge"><#:[% event_count %]> <N:person> <V:has> regi
+stered their interest.</p>
<hr>

<p class="sectionHead"><b>Customer Contentment Call List:</b></p>
<p class="itemHeadLarge"><#d:[% call_list %]> There <V:is> [% call_lis
+t %] <N:person> who <V:is> on the Call List.</p>
<hr>
[% END %]
EOT

# Run it
Template->new->process (\$template, $data);

exit;
[download]

---

🦛

You seem to think that templates are just about replacing variables.

There are more techniques like "includes", were sub-templates are integrated which have sub-templates and so on.

Or embedding programming code inside the HTML for loops or conditional snippets.

And there is reusability, like hacking once a generic "table" template and applying it to different projects.

I have to admit all of this can also be done with pure Perl and no regexing at all, thanks to it's flexibility.

But a framework has a lot of benefits in a team, for instance I don't have teach my colleagues a bunch of best practices if there is already a well documented trail to do it.

Separated HTML-code is not only easier to edit - if it's well done the browser can display it , my editor can highlight it properly and formatting, validation and indentation is easy.

Last but not least, isolated HTML code can be handled by a web specialist without any knowledge of the controlling programming langue, much like SQL-Statements don't need expertise in Perl. That's the main idea of the MVC pattern.

Example from another perspective ... You've spend much time criticizing the design of the monastery, but it's a monolithic framework in pure Perl written 20 years ago.

We can't simply ask several design expert to overhaul the templates, because a lot of HTML is interspersed inside Perl code. (actually it's even much more complicated, because many people added parts in the past)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}