Introduction

Mason is a perl module for the Apache web server. It allows pages to be composed of components. I am considering it to place complex navigation elements (menus and sidebar) as designed by an outside agency.

Currently, our website is primarily static web pages. We publish pages from a web content management system to our servers. The web designers contracted for our new look and feel have designed a complex combination of a top menu and sidebar for navigation. This means that we will have over 40 sidebar menus to deal with. In order to accommodate this, I am looking at a way to componentize these elements so they can be changed once and displayed many time.

OK, the question arises, why not use a portal or CMS that allows pages to be displayed dynamically? That's a good question. Here are some reasons:

• Our site does not really have much HTML. The site is composed of over 15,000 documents listed under various topics. We add documents at the rate of about 4-500 per month. If we had to do this by hand as most web CMS systems do, we would need a larger staff.
• Documents are posted in multiple places because they apply to many topics. Our current publishing system allows us to accomplish this in short order with a minimum of effort and no HTML knowledge.
• The site owners have no intention at this time to have customization. The site is open to the public and does not require registration or any other type of identification. We aren't trying to sell anything and really don't need to know who is viewing our site as we might if we had a product to sell.
• We get between 75,000 and 250,000 page views per day. The site runs on two Unix servers and has served up to 1.2 million page views per day. Static pages help us do that.
• Things don't change dynanmically on the site. They change when someone publishes a new document or prepares a new element for the site. We don't need to construct pages dynamically for that reason. Note that this doesn't mean that the site isn't very dynamic. With all those documents being posted, it is very dynamic.
• We have a broad audience. Our stakeholders cover a wide range of entities and groups with wide-ranging interested and purposes for using the site. We strive to make the site work for everyone.

Links

[Mason Site]

The Mason Home Site

Design Thoughts

Our new design has several elements which have to change based on the page in the site:

• The top menu displays a marker (caret) to the top-level page.
• The left sidebar contains a title for the second-level section in which the page is located.
• The sidebar contains a separate menu for each second-level section (this is the equivalent of the pages in the drop-down menu.
• The sidebar menu has to open to the current page (or parent page if the current page is outside the three level range of the sidebar menu.

Phew!

The goal is to make most of this happen without the maintainers having to strain their brains and configure the entire thing by hand. The visitor should have the advantage of this navigation system to determine where they are without costing us a major chunk for maintenance. (The publishing group will have two full-time people working in it so the publishing system has to shoulder much of the configuration work itself.)

On other complication is that pages can be linked to multiple sections. We need to assure that the page can be located in a primary section and still allow links from the secondary section. This is necessary because some elements (say a meeting) span multiple sections and visitors will want to navigate to that page through different paths.

Caching

I seem to have run into a cache problem with Mason. We are pushing published pages to the servers and the cache is getting updated via a date, but the content of the page is not changing. I need to know some way to turn off caching in Mason or at least limit the caching to some reasonable period of time. This will probably be a very delicate balance between caching and speed for the site.

[10-Jul-2006] I have found the answer to the caching problem. It wasn't really a problem with caching which was working as advertised, but a problem with file update dates. Here's what was happening . . .

We stage everything from servers inside our fire walls to our internet servers. We have a very active site so we stage things every five minutes. Files were updated at one time and then pushed every five minutes to the servers. Mason chaches are set whenever someone requests a file. Here's the deal . . . a file was updated at 00:01, a user requested the page at 00:02, the file was pushed to the Internet at 00:05, but has the 00:01 file stamp due to the replacation of modify dates. In this case the system had cached the old version at 00:02 and assigned that modify date. Thus the cache was newer than the revised file!

The key was to touch (the Unix command) all new files immediately before they are synchronized to assure that they have newer modify dates when they arrive on the Internet servers. This solved the problem.