Templates: Separating Programs from Design

Make web site design changes easier by using templates—HTML pages with embedded Perl code.

If you are running a small web site, then
you are probably responsible for everything—server administration,
the site's content and the CGI programs that produce variable and
dynamic content.

If your site is of any significant size, the work is probably
divided among a number of people. Indeed, most large sites divide
their staffs between the people who are responsible for the site's
content and design, and those who are responsible for the
infrastructure and technical side of the site.

Such a division undoubtedly makes it easier to administer a
site. After all, it is much easier to find someone to write content
or to write CGI programs than to do both. In addition, splitting
the work according to function allows everyone to do what he does
best.

At the same time, such a division makes it difficult for
sites to maintain a uniform presentation style. CGI programs
produce HTML that must match the style of the rest of the site.
This might mean inserting a certain header at the top of each page,
using a particular background color or inserting a graphic on the
side of each page.

In other words, there are two separate sources for HTML
content on a web site. The pages of HTML created by the designers,
and the HTML produced by the CGI programs. If a site does not
change its style often (or at all), the fact that the HTML comes
from two sources does not matter. The designers establish a style
for the site, which is then adopted by both designers and
programmers for their work.

However, many sites have taken to redesigning every few
months, partly due to continually improved technology that allows
designers to create more interesting, exciting experiences on their
sites. Every time a site's design changes, all of the existing
content must be rewritten to fit the new design. Sites that have
split their content between programmer-generated HTML and
CGI-generated HTML will find themselves having to convert two types
of files with two separate staffs.

For example, let's assume that a site has standardized
white-on-blue text. Each time the designers create a new page, they
make sure to include a <body> tag of the
form:

<body bgcolor="blue" fgcolor="white">

In order for the site to have a uniform look, all of the CGI
programs on this site must include a similar
<body> tag at the top of their output.
Here is a basic “hello, world” page that demonstrates how to
accomplish this:

If this program were run as a CGI program from within a web server,
it would produce a short page of HTML on our screens, with a the
text appearing in white text on a blue background. (And yes, we
should use hex codes for consistent colors across platforms, but
this is just meant to be an easy example.)

After creating an instance of CGI (an object module freely
available from CPAN at http://www.perl.com/CPAN), the program sends
a MIME header indicating that it will be sending HTML-formatted
text to the user's browser. Following that MIME header, it sends a
<body> tag, hidden somewhat by the
start_html method that takes care of such tag
production for us.

Finally, we send our short message, marked up in HTML, and
invoke the end_html method, which sends a
</body> tag to end the body of the HTML
text and an </html> tag to indicate the
end of the HTML page.

What happens when the designers decide that white-on-blue
text is passe, and that they would rather have a more modern look
(along the lines of Wired magazine) with
orange text on a green background? It would not be very difficult
for the designers to perform a global “search and replace” on the
<body> tags appearing within the HTML
files on the site. To modify each of the CGI programs on the server
is much trickier.

A Simple Solution

One solution is to put all of our design-related variables in
a library module that we can import into our programs. Here is an
example of such a module called
SiteDesign:

The above module is named by the package
statement. Following that statement, variables and functions are
assumed to begin with the string SiteDesign::.
To avoid problems with the package names when variables are
imported into a program, we have turned off the normally helpful
construct use strict.

Assume that the above code is placed in a file named
SiteDesign.pm, and the file is placed in a
directory named by the special Perl variable
@INC (the list of directories in which Perl
modules are located). Our programs should now be able to include
this library with the statement:

This code is certainly an improvement over the first version of our
program, in that the HTML produced by our programs can be changed
without having to modify the programs. Existing CGI programs do
have to be changed so that they make use of SiteDesign.pm—but you
only have to change your existing code once, rather than each time
the site's design changes.

This approach is useful in many ways, but it does not solve
all of the problems. While we have reduced the amount of work that
a site's programmers need to perform each time the designers change
their minds, we have not eliminated it entirely. The designers
still have to come to the technical staff each time they wish to
make such changes.

Furthermore, there is a practical limit to the number of ways
in which we can affect our programs' output by setting variables.
We could add a variable indicating which image, if any, should be
displayed at the top of each page, another variable indicating
whether an image should be displayed at the bottom of the page,
another variable indicating the font size, yet another for whether
the first paragraph should be centered, and so forth, ad infinitum.
Sure, it would still be easier to change these variables than to
change the output of each CGI program, but this solution does not
scale well to a large number of variables. Would you want to be the
programmer asked to modify 30 configuration variables each time the
site's design was changed?

One possible solution to this problem is to put the variables
in a configuration file, similar to the quiz file that we have
discussed over the last few months. Such a file, particularly if it
were masked by an interface consisting of CGI programs and HTML
forms, would allow designers to modify the site's design without
having to bother the programmers. However, designers would still
have to deal with the large number of configuration variables, as
well as understand what they mean. And programmers would still have
to write code taking all sorts of styling possibilities into
account.

In other words, the use of variables to indicate styling is
better than nothing at all but is far from a perfect solution. What
we would like is a way of creating pages of HTML that could be
modified by designers, and also gives the possibility of executing
code within those pages of HTML.

Trending Topics

Upcoming Webinar

Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report

August 27, 2015
12:00 PM CDT

DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.