Chapter 11

Using Templates

In the state machine shown for the BBS application in Figure 11 5, the run modes 

are depicted as events connecting one state to the next. For each state there may 

be any number of run modes leading to and from the state. As you've seen already, 

run modes are implemented by individual methods in the CGI::Application sub 

class. How do you implement the states?

The common answer would be to use a series of calls to the CGI.pm's HTML 

generation functions.

3

 Listing 11 3 shows a simple version of how the message 

entry screen entered through the  new  and  reply  run modes might be 

implemented. Figure 11 6 shows the CGI in action. As you can probably see, this 

code has a serious flaw the output is unbearably ugly. Fixing this would mean 

complicating the code with table setup, CSS attributes, images, and more. I've 

found that on a typical CGI project at least half the time is devoted to tweaking the 

HTML output to look just right. Worse, using this approach, the display code can 

only be modified by a Perl programmer (you!).

Listing 11 3. Message Entry Screen Implemented with CGI.pm

use CGI  :standard ;

# the _edit method is called from the "new" and "reply" run modes.

sub _edit {

  my $self = shift;

  my %options = @_;

  my $output;

  # output message entry page body

  $output .= start_html("Message Editor") .

             h1("Enter Your Message Below") .

             start_form .

             "Name: " . textfield("name") . p .

             "Subject: " . textfield("subject") . p .

             "Message Body" . p .

             textarea( name => "body",  rows => 4,  cols => 40) . p .

             submit("Save Message").

             hidden( name => "rm",  default => "save",  override => 1);

3. Or possibly just a series of print() statements containing raw HTML. That's so ugly, I can't 

even bring myself to type up an example!

264