Site Layout with Perl Templating Tools

In this fourth part of a five-part series on templating tools, you’ll learn about Perl blocks, helper components, and more. It is excerpted from chapter three of the book Advanced Perl Programming, Second Edition, written by Simon Cozens (O’Reilly; ISBN: 0596004567). Copyright © 2007 O’Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O’Reilly Media.

Perl Blocks

There’s a final way of adding Perl logic to your components, but it’s not used much in the form we’re about to describe. If you’ve got long Perl sections, you won’t want to put a % at the beginning of every line. Instead, you can wrap the whole thing up in a
<%PERL>…</%PERL> block.

However, something you will see quite often in real-life components is the <%INIT>…</%INIT> block. This can be placed anywhere in the component, although typically it’s placed at the end to keep it away from all the HTML. No matter where it’s placed, it always runs first, before anything else in the component. It’s a good place to declare and initialize any variables you’re going to use (by the way–Mason forces use strict…) and do any heavy computation that needs to happen before you do the displaying.

Another vaguely useful thing to know about is the
<%ONCE>…</%ONCE> block, which is executed only at startup–think of it as the Mason equivalent of a Perl BEGIN block.

Our RSS Aggregator

We’re now in a position where we can start putting together our RSS aggregator. The example in this section is taken from some code I wrote for a portal site. It’s worth noting that I threw it together in a matter of around two or three hours. The intention was to support logins, personalized lists of feeds, personalized ordering, and so on. Although I didn’t get that far, what I had after those two or three hours is worth looking at.*

Let’s start by thinking of what we want on the front page. I opted for a two-column design, shown in Figure 3-1, with the left column containing an invitation to log in to the portal and a list of the feeds available. As an additional flourish, the list of feeds are categorized into folders, represented by directories in the filesystem. The right column contains the logged-in user’s favorite feeds, the feeds from a given folder if a folder has been clicked, or a default set of feeds in all other cases.

Figure 3-1.  The RSS aggregator

Let’s begin to build the site. First, we’ll want a header and a footer to take away most of the boring parts of the HTML generation, as in Examples 3-5 and 3-6.

Example 3-5. Header

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html lang="en">

<title> My Portal </title>
<link rel="stylesheet" type="text/css" href="/stylesheets/portal.css">
<body class="pagetable">
<img src="/images/portal-logo.gif" id="toplogo">
<h1>My Portal</h1>

Example 3-6. Footer


Now we’re going to use a slight Mason trick: instead of wrapping every page in the header and footer manually, we use an autohandler, a component that is applied to all pages, as in Example 3-7.

Example 3-7. Autohandler

<& /header &>
<% $m->call_next %>
<& /footer &>

Behind the scenes, Mason pages are processed by one or more handlers, reminiscent of Apache mod_perl handlers. Indeed, $m in our code is the Mason request object, which is similar to the Apache request object.*

In the lineup of Mason handlers, first come the autohandlers, which handle every request; then come dhandlers, which handle particular URIs; and finally comes the ordinary Mason handler for the page you’re trying to process. Our example shows the simplest but most common autohandler: call a header component, then pass this request on to the next handler in the Mason handler chain, and finally call a footer component. This ensures that every page has its header and footer.

{mospagebreak title=Building the Index}

Next, well think about what the index has to be. As we’ve said, we’re going for a two-column design, something like Example 3-8.

Example 3-8. index.html


<td valign="top">
<& /LoginBox &>
<& /Directories &>

$open = ($open =~ /(w+)/) ? $1 : ”;

<td width=4>&nbsp;</td>
<td width=’100%’>

%# Am I logged in ?
% if (0) {
<& /LoggedInPane &>
%} elsif ($open) {
<& /DirectoryPane, open => $open &>
%} else {
<& /StandardPane &>


$open => undef

As promised, the column on the left contains a login box and the directory of feeds. The right-hand side has three states: one pane for those who are logged in (which is ifdef’ed out since user control is left for future expansion), one if a particular directory has been opened, and one if the user has just come to the site’s front page.*

What about the value of $open ? Mason allows components to take arguments, either via CGI or by being passed in from other components. In this case, index.html is a top-level component and will receive its arguments via CGI–that is, if we request the URL, then $open will be set to News. The directory pane component receives its arguments from index.html, and so we pass it the value of $open we received.

Because $open later names a directory on the web server, we sanitize its value to avoid directory-perusal attacks such as passing in a query of
open=../../... We do this in the <%INIT%> phase by replacing the parameter passed in with the first word in the string. If the parameter has no word characters, we set it to an empty string so the remainder of the code acts as if no directory was selected.

{mospagebreak title=Helper Components}

Now, our site is going to be made up of a load of boxes of various titles and different colors, so let’s have a couple of helper components to draw boxes for us. We’re going to allow the box to have a user-defined color, title, and optional title link. Experience has shown that the best way to do this is to create components for the start of the box and the end of the box. The start of the box, shown in Example 3-9, creates a table inside a table.

Example 3-9. BoxTop

<table bgcolor="#777777" cellspacing=0 border=0 cellpadding=0>
<tr><td rowspan=2></td>
<td valign=middle align=left
<font size=-1 color="#ffffff">
<% $title_href && "<a
href="$title_href">"|n %>
<%$title |n %>
<%  $title_href && "</a>" |n %> </b></font></td>
<td rowspan=2>&nbsp;</td></tr>
<tr><td colspan=2 bgcolor="#eeeeee" valign=top align=left width=100%>
<table cellpadding=2 width=100%><tr><td>

$title_href => undef
$title => undef

$color => "#000099"

One thing to notice from this is the |n directive that appears at the end of some of the interpolated Perl sections. The reason for these is to turn off Mason’s default HTML entity escaping code. For instance, if we had passed in a value for $title_href, then this line:

  <% $title_href && "</a>" %>

would want to output </a>. However, as Mason tries to escape HTML entities for you, this would become &lt;/a&gt;–so we need to turn that off.

The box ending code, shown in Example 3-10, is much simpler and merely ends the two tables we opened.

Example 3-10. BoxEnd


<tr><td colspan=4>&nbsp;</td></tr>

As an example of these box drawing components, let’s first dispatch the dummy login box for completeness, as in Example 3-11.

Example 3-11. LoginBox

<& BoxTop, title=>"Login" &>
<small>Log in to Your Portal:</small><br/>
<li> Barcode: <input name="barcode">
<li> Password: <input name="password">


<& BoxEnd &>

When Mason processes that component, it produces HTML that looks like this:

  <table bgcolor="#777777" cellspacing=0 border=0 cellpadding=0>
  <tr><td rowspan=2></td>
  <td valign=middle align=left bgcolor="#000099">
  <font size=-1 color="#ffffff">
  <b> Login </b></font></td>
  <td rowspan=2>&nbsp;</td></tr>
  <tr><td colspan=2 bgcolor="#eeeeee" valign=top align=left width=100%>
  <table cellpadding=2 width=100%><tr><td>
  <small>Log in to Your Portal:</small><br/>
<li> Barcode: <input name="barcode">
  <li> Password: <input name="password">



  <tr><td colspan=4>&nbsp;</td></tr> 

{mospagebreak title=Site Layout}

Now we need to make some decisions about our site’s layout. As we’ve mentioned, we’re going to put our feeds in the filesystem, categorized by directory. Well actually have each individual feed be a Mason component, drawing on a library component we’ll call RSSBox. Our Directories component is a box containing a list of categories; clicking on a category displays all the feeds in that category. As each category is a directory, we can create the list, as in Example 3-12.

Example 3-12. Directories

<& /BoxTop, title=> "Resources" &>

<& /BoxEnd &>

    my $root = "/var/portal/";
    for my $top (grep { -d $_ } glob("$root*")) {
$top =~ s/$root//;
        $Portal::dirs .= qq{
           <li><a href="/?open=$top">$top</a>
        } unless $top =~ /W/;

What’s happening here is that when the server starts up, it looks at all the subdirectories of our portal directory and strips them of their root (in this instance, /var/portal/)to turn them into a link for the purposes of our application. For instance, a directory called /var/portal/News would turn into a link
/?open=News with the heading News. This link redirects back to our home page, where the open parameter causes the DirectoryPane to be presented and opens the feeds in the selected directory. The code skips any directories with non-word characters in the name, so it only generates links that will pass the parameter check on open.

Let’s think about how that pane is implemented. We know that we open a directory and find it full of Mason component files. We want to then dynamically include each of those component files in turn, to build up our directory of feeds.

The trick to dynamically calling a component is the comp method on the Mason request object $m; this is the Perl-side version of the <& comp &> component include tag. Hence, our directory pane ends up looking like Example 3-13.

Example 3-13 . DirectoryPane


% for (grep {-f $_} glob( "/var/portal/$open/*") ) {
% s|/var/portal/||;

<% $m->comp($_) %>
% }

We first receive the name of the directory we’re trying to open. Next we look at each file in that directory, strip off the name of the root directory (ideally this would all be provided by a configuration file), and then call the component with that name. This means that if we have a directory called Technology containing the following files:


then calling <& /DirectoryPane, open => "Technology" &> would have the effect of saying:

  <& /Technology/01-Register   &>
  <& /Technology/02-Slashdot   &>
  <& /Technology/03-MacNews    &>
<& /Technology/04-LinuxToday &>
  <& /Technology/05-PerlDotCom &>

The standard pane, shown in Example 3-14, appears when no directory is open. It consists of whatever feeds we choose to make default.

Example 3-14. StandardPane

<& /BoxTop, title=> "Hello!", color => "dd2222"&>
Welcome to your portal! From here you can subscribe to a wide range of
news and alerting services; if you log in, you can customize this home
<& /BoxEnd &>

<& /Weather/01-Oxford &>
<& /Technology/02-Slashdot &>
<& /News/01-BBC &>
<& /People/03-Rael &>

So what’s in the individual files? As we’ve mentioned, they make use of an RSSBox component, and they simply pass in the URL for the feed and optionally a color, a maximum number of items, and a name for the feed. They also pass in a parameter to say whether we want to display just the titles and links for each RSS item, or the description as well. For instance, /News/01-BBC looks like this:

  <& /RSSBox, URL =>"
  Color =>"#dd0000" &>

whereas Rael Dornfest’s blog looks like this:

  <& /RSSBox, URL =>,
  Color=> "#cccc00", Title => "Rael Dornfest", Full => 0 &>

As we’ll see in a moment, the beauty of this modular system is that we can have components that do things other than fire off RSS feeds if we want.

Please check back next week for the conclusion to this article.

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye