#!/usr/bin/perl -w
use strict;  $|=1;

my $formbuf=<<'OKAY';
This is a | test template ||| you like?

OKAY

my @parts = &GetMultipartTemplate($formbuf);
print "$_. ",length($parts[$_])," $parts[$_]\n"
  for (0..$#parts); # test output

sub GetMultipartTemplate {

    # Returns pipe-separated parts of a form
    # Usage: @parts = GetMultipartTemplate($formbuf);

    my @t = split(/\|/, shift);
    return @t; # yes returning a reference is better..

}
[download]

In my experience the most important thing is to try and get as complete as possible an idea of what you are trying to do and what you may be asked to do in the future, so you don't for example build a weak authentication architecture, and have to revamp everything.

If you are thinking portability realize this could mean moving to servers running different OS's, with different installation permissions, and maybe in different languages.

If you are thinking of localizing into other languages (particularly two-byte languages like Japanese) you may want to test whatever solution you use first. Some encoding systems might not work well in embedded perl code, for example Japanese Shift Jis (SJIS) is like binary and will once in a while break a Perl script. If you can change encoding on the fly in that case (e.g. convert 7-bit EUC to 8-bit SJIS) you will be okay. Incidentally the above example will not always work with SJIS, since some two-byte characters include the same value as a pipe mark. So splitting by a multibyte value is better. Recently a Japanese programmer didn't believe it when I told him so until he tried to figure out some code didn't work.

Also, consider how dynamic your site's basic templates will be, for example do you have a menu which highlights differently depending on which section you go to. I've tried both programmatic ways and the "let the designer handle it" ways, and maybe the above templating solutions will help. You will need to train your team and produce a document so that people who come along in the future don't break something or continually bug you to train them too. Also think about what schedule and volume of updates will be needed, and whether they will be primarily design or functionality related.

One interesting strategy I found once was with a site that had no database engine, and I built a system called Magic Hands to generate programmatically a thousand static pages of layouts including little idiosyncracies. The system also uses Gimp from Perl to do a good deal of automatic resizing, thumbnail creation, and composition with frames and shadows, i.e. alpha masking. For example with this I was able to write a small subroutine to create thumbnail-based navigation with highlighting so that you could move through a series of pages (this was a hotel guide) by clicking successive thumbnails in a circle. Just two template html pages and a block of code were needed for this.

I don't know if you can do that with Mason or Toolkit. But if you are able to install any modules on the server you like, then perhaps those template modules are good. The above system I built to solve a specific problem: very short time frame, repetitive layout, and the knowledge that we would have changes made at the last minute despite the deadline. As it happened this worked since I got a whole CD worth of new images and after normalizing file names and so on, was able to rebuild the entire site in five minutes, with non-engineers able to take over all editing in the future. So you need to think about how this may be passed on to people in the future and how much would be touched by non-engineers.

Another thing to consider is how involved your interface (for example form validation, redisplay and editting, error messages, etc) will be. Consider that Javascript is great for some things but you may have to edit a number of copies of the same script, or you may run into incompatibilities based on browser version. Perhaps Javascript needs to be modified on the fly too. So long as you can discover the balance of processing needed early in the game you will be able to test the above solutions to see which is best for you.

One thing I do remember, is that it was quite easy to slurp a template file into a buffer, replace a few keywords with the necessary text, and send it to the user's browser. But I found that when I had to build a complex form to display a user record from a database, it was quicker to take the html template I had and turn it into a perl program which I eval'd after setting a couple of variables in the main program which loaded it. Perhaps CGI.pm based form output commands are elegant, but you could actually load this perl program into netscape and it would look like html.

It may be that things are quite simple and you can get away with a few simple template HTML files which you rip apart and modify on the fly. But a more complex system may very well benefit from tools that can handle nested, object oriented systems. So I'd recommend thinking carefully about what your needs are, then taking a look at the solutions other people recommended. It seems these tools have matured quite a bit so I know I'll take another look myself. If anyone has good experiences with the above tools or thinks I'm wrong somewhere would like to hear comments.