Strategy for migrating Perl CGI to Template Toolkit?

Question

I have a relatively large legacy Perl/CGI/DBI web application which generates HTML on-the-fly piece by piece. We are reworking the HTML being produced, to come in to compliance with HTML 5 / CSS 3. This would be a good time to move to some sort of template system. We do NOT want to engage in a complete rewrite, and thus do NOT want to migrate to a framework such as Catalyst.

I'm thinking that Perl Template Toolkit might be our lowest-impact means. I'm re-reading the venerable Badger Book to study up on feasibility.

My question is this. Has anyone here migrated "old school" Perl web code to Template Toolkit? Are there any tricks you can share for minimizing the rewrite/rework needed? We have not 100% decided on Template Toolkit, either. If there is an alternative which we should consider?

What problem, specifically, are we trying to solve? We're generating invalid HTML and need to clean that up. Since we're cleaning, we want to produce fully-valid HTML 5 and, to the extent practicable, valid CSS3 and Javascript. We use jQuery, jQuery UI widgets, and AJAX via jQuery. We have typical Page Controller MVC architecture except no View layer as such. We'd like to go to some sort of template system but don't want to rewrite everything (or much of anything!) to migrate.

Thank You! Ed Barnard, Cannon Falls MN

Answer 1

Here's what I've found, as I've moved my practice from CGI.pm to TT, and what I've also learned along the way using HTML::Mason, HTML::Template, Text::Template, and working with ERB and HAML in Rails.

1. The more logic you have in in your displays, especially if it is written in a display specific language, the less fun you're going to have.
2. I've come to prefer HAML for the reduction in size of the contents of my templates [ In HAML, closing tags are implied by indentation ]
3. Perform as much of the logic to compute the various dynamic bits of the page before you drop into the template, in the application's native language. [ call view methods, before engaging in rendering ].
4. In relation to (3), by using methods, instead of inline display/rendering logic, you can make your templates declarative, so while you might be performing logic in the middle of the render, your templates don't have a bunch of IF/THEN/ELSE logic causing clutter.

Let's imagine a reasonably small, contrived web page made up of a header, and footer and a body. Let's assume that the footer is completely static, the body changes every time a new page loads, but the header only changes when a user logs in/out.

You can imagine the header containing code like this:

<header>
[% IF $user.is_logged_in THEN %]
   Hello [% $user.name %] - <a href="/logout/user/[% $user.id %]">Log Out</a>
[% ELSE %]
   Please <a href="/user/login">Log In</a>
[% END %]
</header>

But you're better off in the long term doing this in header.tt:

<header>
  [% user_info($user) |html %]
</header>

and this in View::Helpers::Header.pm:

sub user_info {
   my $user = shift;
   if ($user->{is_logged_in} ) {
     return "Hello $user->{name} - " . logout_link($user->{id});
   }
   else {
     return "Please " . login_link();
   }
}

sub logout_link {
  my $userid = shift;
  return qq(<a href="/logout/user/[% $userid %]">Log Out</a>)
}

You can, of course, implement the view helpers in TT rather than pure Perl, and I don't have any kind of numbers for you, but if you've done all of your logic in Perl already, you can refactor the Perl into modules (if it isn't there already), instead of re-coding them in TT.

Answer 2

As part of your test suite, consider an HTML validator like HTML::Lint or HTML::Tidy.