<TMPL_VAR NAME=PATH>
[download]

Considering that most webhosting companies do not offer solutions such as embperl, Mason, Apache::ASP or others of the sort, what is the most efficient way to work with, build and maintain these websites?

Webhosting is a competitive market and it sounds like you are developing a non-trivial site. Hosting your site could mean a lot of income to whichever web-hosting provider you use. They should be willing to provide you with the tools that you require in order to get your business. If "most webhosting companies do not offer" what you need seek out the ones that do and give them your business. Other developers will make the same choices as you and the providers that offer better services/features to the site development/maintenance team will flourish.

Yeah, I think I should have specified why my worry about webhosting providers. You see, many of our customers already come to us with a webhost that they have used in the past and are happy with. Its my company's policy not to vouch for other company's services, so we tend not to try and push them away from a service that they are already happy with.

In some cases (our larger, corporate) clients own their own servers, but then its likely that I'll have to get it through to the thick-skulled-dinosaur-it-manager that compiling DBD::Oracle requires that you have at least Oracle client installed on his HP-UX (get the drift?).

Bottom line is that unfortunately I am not always able to choose out of a vast quantity of hosting options, and that's why I got stuck with my MakeHTML($template,%HASH) solution. :o/

Thank you for the great advice on HTML::Template, I've skimmed through and seems to be exactly what I was in need for! (and my most common webhost, HWay, has it in their module list)

I understand getting stuck with a less-optimal solution because of choices made elsewhere. About all you can do it inform the client of the ramifications of their decision and prepare.

In the first case I would handle it like this. Tell the client company:

Since your current webhost doesn't support A, B, or C we can develop your project in X weeks and it will take about Y effort to support in the future. It will scale like Z. If you find a webhost that supports A, B, and C then we can implement it in T weeks and it will take about U effort to support in the future and it will scale like V.

Break it down in such a way that both their operations staff and accounting departments can both understand the ramifications of the choice they've made. If they choose to stay, at least they know what tradeoff they made (and hopefully they'll come back to you when they realize the error of their ways). Also, if you can get your company to change policies and start recomending a (or some) particular webhost(s), you may be able to cut a deal w/ the webhost that would let the clients get a lower rate (since you'd be bringing them in in bulk).

In the second case (and I've been in that EXACT same spot before w/ HP-UX and Oracle even). be sure you include in your specifications details requirements of what they must have installed (preferably in an early spec that upper-managemet signed-off on). Make sure this is widely distributed to all parties related to your project in the client company. Make sure you are ready so if it comes down to the dinosaur manager problem you can place blame squarely on his/her shoulders and show him/her that upper management has already signed-off on it. It still isn't a fun fight to have, but being prepared can make it an easier win.

I too agree with lhoward about both HTML::Template and his views on choosing webhosts. I had been using custom "special" tags and then parsing this template. I've now begun using HTML::Template and am quite happy that I am. In addition to generally making HTML editing MUCH easier, it also allows for loops and some other nifty controls. Good luck, Doran

Thanks for the suggestion but, that won't work...

You see, the main idea behind the templates is to allow my designers to keep to HTML and not have to even think about splitting a file up into head.tpl, foot.tpl. row.tpl and so forth. Come to think of it, I don't think I would use it even if I where doing all of the work myself because the of the template mess you might get into when doing a complex designed site. Keeping track of each tpl file would become, as lhoward put it, a maintenance nightmare.

But thanks anyway.

I also store all of the page content in the database. Now there's also a web interface (with permissions and security checks) where various people can update the content.

Instead of building pages dynamically from the web server, I have a backend program, either run from cron nightly or activated automatically which walks through the hierarchy and updates any pages that have changed. I can afford to be a little bit inefficient with the substitution and transformation, because it doesn't happen in real time.

This seems to work pretty well for sites of only a couple of hundred pages, with only a few changes every day. Scalability isn't on my list of worries right now.

I've used that exact same setup in the past for larger websites (+500 pages), in combination with SSI for header/footer stuff. I'm not terribly worried about the sites that need constant work or are large projects where we have to allocate alot of programming man-hours, since those usually have small design update issues.

The amount of effort put into changing 1 single script tends to be alot more than changing the entire site look and feel, and that's where we hit the hard cold bottom. Smaller sites shouldn't require a programmer's man-hour (which is more expensive than a HTMLers man-hour) when the maintenance is purely synthetic.

I'm rambling... What I wanted to say is yeah, I like your setup and I've used it in the past, but I'm looking for a solution for the smaller, everyday sites (40 pages tops).

use CGI qw/:standard/; # for html shortcuts
use CGI::FastTemplate;
# code here
# creates an HTML string called $template, i.e.

 my $template =  table({-width => "641",
                 -align => "center",
                },
                Tr(td(
                      font({-color => "#3399CC"},
                           "There were errors in the form input:")),
                      (map {h2("$_:"), h3(ul( map (li(i(mapfieldname($_))), @{$errors{$_}}) ))} keys %errors)

                     )));

# and now show the results
my $tpl = new CGI::FastTemplate("/home/httpd/html/templates");
$tpl->define( finished => "output.tpl" );

$tpl->clear_href;
$tpl->assign( { TEMPLATE => $template } );
$tpl->parse( FINISHED => "finished" );
print header();
$tpl->print;
exit;

It works like this:

• I have a database holding the info for all the pages (title, name, Keywords for meta tags, and parent-child relationships.) The database isn't vital to the concept, but lets us modify the site structure easily.
• I have a small script that consists of two subroutines, one that loads all variables for a given page from the database, and another that uses Text::Template to load a given file. I use the prepend option of Text::Template to load that template with this very script (So my templates can in turn call templates, etc)
• Actually, I have several variants on #2, each with a slightly different purpose. One writes an HTML file (or multiple files). One displays the content parsed into HTML, but without writing a static HTML file, another does the same thing, but wraps the text of the content in TEXTAREA fields so it can be edited, etc..

<!!&SiteBuilder_Load($Header,$ID)!!>
 Uneditable content
<!!$BeginText!!>
Editable Content
<!!$EndText!!>
more uneditable content
<!!&SiteBuilder_Load($Trailer, $ID)!!>
[download]

1. I named my html templates with a .htmlt extension, so I'd know they were templates.
2. My variable placeholders in the template files were designated as allcap names of their matching perl variable name. Example, if I had $title in my .cgi, then I'd have a $TITLE in my .htmlt.
3. In my .cgi, I'd have the following:

       open(TEMPLATE, "mypage.htmlt") or die "can't open mypage.htmlt: $!
   +";
           local($/) = undef;
           my $template = <TEMPLATE>;
       close(TEMPLATE);
       $template =~ s/\$TITLE/$title/g;
       print "Content-type: text/html\n\n";
       print $template;
   [download]

Yeah, I know what you're saying... This is what I have (and what I'm trying to run away from):

# parses HTML files as templates
#################################################
sub MakeHTML {
    
    my ($file,%HTML) = @_;
    my ($line,$tag,$html);
    
    # open HTML file
    open(READ,$file) || return(0);
    foreach $line (<READ>) {
        foreach $tag (keys %HTML) {
            # substitute tags
            $line =~ s/\[$tag\]/$HTML{$tag}/gi;
        }
        # gather parsed HTML
        $html .= $line;
    }
    close(READ);

    return($html);
}

# assign things like
$STUFF{'myname'} = 'John Burbridge';
$STUFF{'myage'} = 26;

# then print it
my $html = MakeHTML('/path/to/template.htm',$STUFF)
    or Errors('couldnt parse the template');

print "Content-type: text/html\n\n";
print $html;
[download]

and the template file would look like this:

<html><body>
My name is [myname] and I am [myage] years old.
</body></html>
[download]

Sure it looks pretty simple and handy at 1st glance, but beleive me: ITS A BAD HABIT. I had to learn this the hard way...

This probably isn't the answer you're looking for either, but have you thought about using PHP? We use PHP quite a bit because:

1. It was easy for me to learn, already knowing Perl.
2. It performs reasonably well in CGI or Apache module mode.
3. Relatively fast development cycle.
4. Many hosting providers offer it without significantly increasing costs.

1. No CPAN
2. Not quite as elegant as Perl
3. Not as good at regular expressions
4. Not Perl :)

PHP has "include" functions for importing the things you want to use over and over. We use includes for the headers and footers so that the page content is separated from the page navigation and look-and-feel..

I would not recommend PHP for anything where you want to have some very powerful functionality and have a tight deadline. It can be quite tedious to do serious application development...at least in comparison to Perl.

use CGI qw/:standard/; # for html shortcuts
use CGI::FastTemplate;
# code here
# creates an HTML string called $template, i.e.

 my $template =  table({-width => "641",
                 -border => "0",
                 -cellspacing => "10",
                 -cellpadding => "0",
                 -align => "center",
                 #-height => "734",
                 #border => 1
                },
                Tr(
                   td(
                      h1({-align => 'left'},
                         #img({ -src => "/anim_logo.gif",
                               #-width => "375", -height => "56"
                         #    }),
                         br,
                         font({-color => "#3399CC"},
                              "There were errors in the form input:")
                        ),
                      (map {h2("$_:"), h3(ul( map (li(i(mapfieldname($_))), @{$errors{$_}}) ))} keys %errors),

                      h3("Please click your ",
                         a({href => "javascript:history.go(-1);"}, 'BACK'),
                         " button and correct the pro

To answer your final question: I once wrote some scripts that were very similar to the html::template concept, but I did not use it in a cgi context. I kept a mirror of my html tree, except all the files were templates. A short little find script would run through all the directories, generate the static html pages based on the templates, and finally move them all into the live html tree. You then have a database driven site without the database!

As an added bonus, it was quite easy to move the site from the old style generated static pages to a live database driven site. The output just goes to the screen instead of the file.

I think this was what you were asking, hope it helps.