Exploring my Firetowers website
By no means do I consider myself an expert programmer. Hell, I can barely call myself a novice, really. But I do tend to have an understanding of the basic principals of web programming, and when I have something in mind for a project, I’m pretty good at laying out a design and then building a framework.
When it came to my firetower website, I had a few things in mind. I wanted people to be able to see a map with locations of all the firetowers I’ve been to. I wanted links to each location, and descriptions of the towers with photos. So, what I had at first was a single page with an imagemap with little firetower icons that you could click on in order to see descriptions of the towers.
But then I started to realize how it’d be neat to have all the descriptions in one file and dynamically generated HTML, so I could easily add more if I wanted, without having to make another HTML page for each one. If I were to visit a bunch more towers, this would be easier for me in the long run. This approach also has the added benefit of efficiency in that the content that would normally be repeated in every HTML page (such as the header, body tags, and everything else) can instead be written in one place and doled out on the fly.
The reason I decided to use Perl was because, really, it was all I had used before. Now that I’m learning a bit more about both CSS and PHP (thanks to setting up this site), it’d be interesting for me to remake the firetower site and see whether I can do a better job. But back then I was sort of afraid of both those things because they seemed so complicated.
Anyway, I spent several days (or was it weeks?) working on the code, including several major revisions which lead to increasing efficiency. Originally, several routines were all in their own files (completely isolated scripts to handle various input, always passed back and forth between scripts as environmental variables), but I found I could save a bit of trouble by using a BASIC-style top-down approach with subroutines (I know why this can be bad, but in the case of the small firetower script it worked well). What I ended up coming up with seems to work pretty well.
The basic flow of the program is like this:
Someone decides to visit the site. Cookies are checked and at this point one of two things can happen. 1. The user doesn’t have a cookie set that says they’ve read the disclaimer page (or they have a garbled cookie, or a cookie saying they disagreed to the disclaimer), so the disclaimer page is printed. 2. The user’s cookie says that they previously agreed to the disclaimer, which means that they can see the content of the site.
At the disclaimer page, the user can choose to disagree or agree. There’s also an option to use “text mode” which means that upon seeing the content of the site there will be a list of plaintext links to the tower information instead of a graphical map. This is set in a cookie so that the setting is retained throughout the visit, as well as for future visits. The option can also be changed later.
The main content of the site is handled with a few routines. The first thing that happens is a generalized header is printed which contains HTML from content-type through setting the font. So, basically, the first chunk of HTML. Next, depending on what the user’s preferred navigation choice is (text, imagemap, or google map), the main chunk of content is printed out. Since there’s also an option to re-read the disclaimer page, that gets handled here as well. There’s also an error trap in case unexpected input is passed to this part of the script – it would result in the error “Incorrect argument specified”.
After this, a generalized footer is printed containing the navigation choices. These choices POST back to the main script so the main content can be reprinted if the user wants to use google maps instead of the imagemap.
All that’s left at this point is what happens once the user clicks on a link to see more information about a firetower. The information is passed back to the main script as an environmental variable which is then passed to a separate library that contains all the information about the towers. All of the printing of tower information is done here.
A few simple benefits of my design are: 1. since cookies are checked every time the script is called, there’s no risk of the content being displayed if the cookie isn’t properly set, and 2. the firetower data library is easily expandable, and 3. the main script is pretty compact – without comments, it’s less than 10KB, and much of this is just HTML content that’s outputted to the user.
