#! /usr/bin/perl -wT
use strict;
use CGI qw( :standard );
$|++;

print header, start_html( 'Test Page' ),
      
      p( "Here's a pretty picture; enjoy\n" ),
      
      img( { src=>'../images/back.gif', 
             align=>'CENTER' }, "" 
         ),

      p( "Cool, huh?  When ready, go", 
         a( { href=>'../index.html' }, 'Home' ) 
       ),
      end_html;
[download]

The use of relative directory references is the point under discussion. This is a simple example, one that works when /images and /index.html are created directly below the public document directory. However, bear with me as I try to outline the scenario. It's not that complicated, but it is involved and demonstrates a real-world situation, one similar (at least in spirit) to those encountered by many of you on a regular basis.

Suppose that you're working in a large organization, as I do by day, and that a remote IT department manages multiple web sites for companies owned by (or affiliated with) that organization. Furthermore, the organization is so vast that timely communication between the various teams involved with the content and scripting of the child sites is difficult to manage (at best) or completely forgotten (at worst).

Since the parent company manages the web server and hosts the sites for all the child companies, their "designers" (yes, I use the term loosely) have elected to set up the various sites as follows (please forgive the ASCII artwork):

   parent's public document tree
     + parent site images\
     + parent topic 1
     |   + subtopic 1
     |   + subtopic 2
     + parent topic 2
     |
     + child site "root" 1
     |   + child site images
     |   + child topic 1
     |   + child topic 2
     |       + child subtopic 1
     |       + child subtopic 2
     |
     + child site "root" 2
       # and so on
[download]

The idea being to make it possible to share common branding items between all sites in the enterprise without the problems of duplicating those shared elements. It also provides each child site with reasonable flexibility regarding their own content and presentation of that brand. The parent has dictated certain requirements for the appearance of a page, the logos used, and so on. For example, certain backgrounds, buttons, and so on are available to every child site by linking to the parent's /images folder.

Now, before you say that just isn't done (it is) and that it's a completely stupid idea (there is, from certain points of view, an elegance to the architecture) think about the challenges that adds to your simple script. For example:

• How can you guarantee that ../images contains the correctly branded logo (back.gif)? Indeed, ../images may not even exist because you're not the one deciding where the script gets called from.

• If ../index.html is supposed to return to the main page for the child site, you cannot guarantee that you'll get the proper results. You should, but there's a risk that you may not. Remember, you have no control over the content of the site itself.

Furthermore, imagine that this is one of those all too common companies that distinguish between "programmers" and "designers," meaning the artwork is created in one deparment, HTML markup is created in another, and that programming is done by a third. Each has a different culture and political climate.

Hard code the references, you say? OK, but what happens the site undergoes a makeover, the filenames change, the directories are reshuffled, or new topic areas get added? By hardcoding, you've modified the files, thereby tying yourself to maintenance each time the site changes. This is a bad thing because it means that every so often, you have to maintain your script. (Personally, I prefer to work on projects (or phases) that can eventually be finished.)

Redesign the site to use Mason or other templating alternatives? Ideally, yes. Not possible here.

Now, here's where I may be going off-base, but since I have no control over the markup, the designers don't want my opinions or suggestions, and I have no access to or control over the server, I needed a reasonable way to mimic the look of the site, use the proper branding tools, and make updates easy.

I did it by taking a page from the child site in question, ripping out the content, and saving the remaining parts into separate files loaded when the script is run. Dump the header, dump my script results, dump the footer. Voilá. This handles the problem with makeover changes, but since the relative path from the \cgi-bin directory may not resolve to the same directories that they do from the page calling your script, that still leaves a problem.

Enter the <BASE> tag, which (according to W3C), "specifies an absolute URI that acts as the base URI for resolving relative URIs."

After adding a BASE tag to the header file that I dump, the relative references worked perfectly. Furthermore, I can now automate the process of generating the header and footer files using another script (which will also add the BASE tag to the header file). while there may be some continued maintenance associated with the "dump" files, it can be performed simply and cleanly in very short order.

Moral: If you find yourself running into problems with relative directory references and that can't change, consider the BASE tag.

Question #1: Are there dangers with this? Is it widely supported? Are there easier ways to do this?

Question #2: Are there other, common (but little publicized) tricks for making it easier to write CGI scripts in this type of context? What other strategies do you use to deal with the communication, political, and environment factors in this little story?

BTW, I have considered moving on. That's not the sort of solution I'm talking about--unless you're seriously willing to make me an offer, one that lets me work from my present home, allows me to live in the style to which I wish to become accustomed, that lets me bring more of my skills and my experience to the table. (I'm getting tired of being *just* a programmer). *grin*

--f