http://qs1969.pair.com?node_id=150608


in reply to HTML::Template Tutorial

I'd like to add to jeffa's excellent tutorial by mentioning HTML::Template's query() method, which allows Perl programmers to determine which parameters are used on a given template.

Using HTML::Template, Perl programmers set the parameters used by the templates but don't need to worry about the templates themselves, provided they've agreed with the template developers what the parameters are called and where the templates are stored.

This separation of back-end programming and front-end development creates a problem: Which back-end code needs to be called in order to set all the parameters required by the template?

One approach is to determine which features are required on each page beforehand. The Perl programmer might write a mod_perl handler as below:

    # Derive the template's filename from all characters in the
    # requested URI
    # after the last /, making sure we only allow word characters
    $url =~ m!/(\w)$!;
    my $template_filename = $1 or return DECLINED;

    my $template = HTML::Template->new(filename => $template_filename)
        or return SERVER_ERROR;

    if ($template_filename eq 'results') {
        # Write some code to generate a list of results and set
        # corresponsing parameters on $template
    } elsif ($template_filename eq 'weather') {
        # Write some code to find out what the weather is like and set
        # template parameters
    } elsif ($template_filename eq 'users' or $template_filename eq 'p
+eople') {
        # Write some code to generate a list of users on the site and
        # set some template parameters
    }

[download]

This approach is inflexible: if the HTML developer decides to include existing functionality on an additional page, the Perl logic must also be updated. One way to avoid this is to set all the possible parameters for every request. This will be very slow for a typical Web site where most of the code isn't used for each request.

The cleanest way to deal with this problem is to use HTML::Template's query() method. This method allows us to find out whether the template uses a given parameter or not. For example, the weather code in the example above might set parameters called temperature and cloud_cover. To ensure that we only run those parts of the Perl program that the template requires, we could do something like:

if ($template->query(name => 'temperature' or $template->query(name =>
+ 'cloud_cover') {
   # The code to find out what the weather is like goes here
}

[download]

This is much better: HTML developers can use the weather parameters on any of the site's pages and Perl programmers don't need to update the code. It's likely that there will be lots of calls to the query method, though, which we can replace with a single call that takes no arguments to retrieve all the parameters used on the template: 

my %param= map($_ => 1) $template->query();

if (exists $param{'temperature'} or exists $param{'cloud_cover'}) {
    # The weather code goes here
}

[download]

Replies are listed 'Best First'.
Re: Using HTML::Template's query method
by stiggy (Acolyte) on Oct 04, 2002 at 22:57 UTC
    I am unquestionably quite a bit biased on this topic. I wrote the CGI::Application module to solve exactly the problem you describe, so I have just a few opinions on the subject of run-mode management. :-)

    IMHO, looking at the parameters in a template is ripe for failure. Unless you have a strict naming convention, I cannot imagine how you are going to assure that parameter names are not innocently reused for varying purposes from template to template. Looking at the name of the template is a LITTLE more sane. At least you have uniqueness -- unless you have some space-age file system which allows two files with the same name in the same directory. The idea of looking at the template name is really the functional equivalent of any "Server Page" system, in that regard. The only difference is that your code is not mixed in with HTML, as it usually is in ASP, JSP, Mason, EmbPerl or ColdFusion.

    Not having code in a HTML an improvement, but there is still one HUGE problem in a server page architecture. Each template file (or "server page") represents a single screen, but it DOES NOT represent the ACTION which brough you to this screen! On the web, there is very often more than one way to get to a particular screen. Server page systems, including the system you’re describing, are incapable of cleanly implementing this behavior.

    Consider a simple database application which allows an administrator to search, add, modify or delete an item. Imagine that your "search" function displays a list of matching results -- an "item list" screen. Also imagine that when you delete an item the user is returned to the item list screen.

    Here are the functions of this hypothetical application, including the two we’ve mapped out: 

        ACTION        =>  SCREEN
    ---------------------------------
    "start"       =>  "search form"
    "search"      =>  "item list"
    "add item"    =>  "item detail"
    "view item"   =>  "item detail"
    "delete item" =>  "item list"
    "update item" =>  "item list"

    [download]

    As you can see, this application has only three screens, but it has SIX different actions which might be triggered. In a server page system you would have to put switch logic in each screen to figure out what to do: 

        ### list screen ###
    if ($mode eq "delete") {
        delete_item();
    } elsif ($mode eq "update") {
        update_item();
    }
    display_item_list();

    [download]

    Now, imagine a switch like this in every screen! And what do you do if you actually want to add a function, or change (for example) the "update" action to return to the "item detail" screen? You have to edit a spider web of files to make even the smallest change.

    And the worst: Your code is now looking a lot like CGI "scripting" circa 1995!

    CGI::Application allows you to decouple your screen ("pages", "templates", "states") from your actions ("run-modes", "transitions"). This means that you can cleanly share a screen between actions without having to write switch code to do so. Instead, you simply set up a "run-modes" dispatch table in an object-oriented Perl package which inherits from CGI::Application. Each mode maps to a Perl method, which in turn uses HTML::Template for output.

    If you're interested in learning more about CGI::Application, I wrote an article about it:

    Using CGI::Application
    http://www.perl.com/pub/a/2001/06/05/cgi.html

    Also, rob_au has offered a review of the module.

    Warmest regards,

    -Jesse-

[reply]
[d/l]
[select]

In Section Tutorials