Site Layout with Perl Templating Tools (
Page 1 of 4 )
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">
<head>
<title> My Portal </title>
<link rel="stylesheet" type="text/css" href="/stylesheets/portal.css">
</head>
<body class="pagetable">
<img src="/images/portal-logo.gif" id="toplogo">
<h1>My Portal</h1>
Example 3-6. Footer
</body>
</html>
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.
/ 3 
