In this installment of my ongoing "Why I Did It" series, I'm going to finish discussing one of my favorite new site building techniques: "Working With Walnuts" ~ a conceptual approach to the use of "includes" for fast and easy page formatting, and simple site maintenance. Check it out:
The first part of this article laid the groundwork for today's discussion by outlining what "includes" are, and some of the things that they're used for. I also showed you the syntax for using includes with Microsoft's popular "FrontPage" visual HTML Editor and site maintenance tool. Part two catered to those Webmasters who do not use FrontPage, instead it discussed options such as PHP and Server Side Includes (SSI).
Today I'll reveal what all this talk of "Walnuts" is. But first, I'm going to show you the second type of "include" that I was exposed to:
Remote JavaScript
While not technically in the same category as the other types of includes in this discussion, using remote JavaScript calls is an easy way to streamline your HTML code, and speed up the download time of pages which make heavy use of the same JavaScript. For instance, say that you have a large chunk of scripting used for a snazzy navigational interface, and you need it on every page. While you could make a template page with this code in the HEAD tag, you would still have multiple pages to edit if you later on decided to make a change, such as add a new content category, or additional galleries. Using a remote JavaScript call will simply the process for you. This snippet of code is the call, and should be placed in your HEAD HEAD tags:
SCRIPT LANGUAGE="JavaScript" SRC="navigation.js"/SCRIPT
You will notice that unlike a standard JavaScript container, there is no traditional scripting between the SCRIPT /SCRIPT tags, but there is instead a source attribute: navigation.js that points to our new script file. This is a text document that contains the JavaScript, without the SCRIPT /SCRIPT tags as they appear here in the remote call. Now if you wanted to update the script, you only need to edit the navigation.js file, and the changes will be visible on every page calling it!
I have also used this technique for master JavaScript files (javascript.js) that contain all of the base scripting that I'd like to incorporate on a site, including "bookmarking" code, a "right click disable" code, and more; anything that I wish to perform globally on all of my site's pages. Another cool benefit is that if one or more (but not all) of my pages requires a different bit of script, I can still have another SCRIPT /SCRIPT tag underneath the remote call, or even additional remote script calls — a flexible, win-win situation.
What's With the Walnuts?
Well, I've shown you four types of includes now, and given you a wide variety of uses for them. Now it's time for me to bring it all together and illustrate the power of these bits of code with another of my little stories:
Dawn's new site features a relatively massive and continuously expanding content database; a happy little collection of porn and more. One that could easily be marketed through a variety of front-ends. When she informed me that her last pay site had over 500 pages of content — and that she expected MUCH more in this new site, I realized that some form of centralized content management was called for. There was no way that I was going to set myself up for hours (or days!) of tedious, manual page updates when an unforeseen change in the structure of the site needs to be made. It was time to be clever:
From the previous installments of this series, you will have seen how I use a variety of includes to replace the BODY tag on sites not employing CSS: a page formatting technology that she uses on her new site. Standardized headers and footers were also easily produced with includes, as was my navigation; an often complex bit of coding.
The problem was however that I have seen pages that used multiple includes fail to load properly, and given the traffic load that we'll be sending to this site, we want it to be as stable as possible. That is why I avoided a database-driven solution. Say what you will, I have seen sites programmed and operated by folks far more technically savvy than I "shit the bed" with mySQL errors. Why bother with all of that if a simpler and more stable solution was at hand?
It could all be done using the series of includes that I had already built into the Beta site; but what if I took all those includes, the JavaScript, navigation, credits, and centralized table structure, and put them on one long page. I could chip away at the code, and streamline it as much as possible. I could take this template, (that did not use includes, but had the full HTML code on it. I could then split this page into two pages, breaking it in the main TD /TD tags.
I would now have only two includes: header.php and footer.php, and since these two pages together weigh about 5k, they will not only load quickly, but stay in cache for the remainder of the surfer's visit. This will drastically reduce my server load, speeding up the site.
My goal was develop a "container" for my content. A simple template that could be duplicated and modified by inserting a text file between the !-- CONTENTS -- !-- /CONTENTS -- tags. The same content files could then be easily reused, inserted into other "containers" — to mass produce "different" sites all sharing the same content back end. A container that would cleanly envelop my content, regardless of its nature; a container that was like a Walnut shell! I needed a virtual Walnut shell, and my content would be the nut, safely and totally enveloped in this outer container, a template divided cleanly in two halves:
This is the code for my ENTIRE main page template, or "The Walnut" as I've come to call it:
?PHP include("header.php"); ?
!-- CONTENTS --
!-- /CONTENTS --
?PHP include("footer.php"); ? I don't need to go and change a ton of stuff, it's just one or two lines of text, on one page!
A little "Notepad" copy n paste, and Dawn's text and images are placed into this template, then it's a simple matter of "right click, save as:" Sure, there's lots of cool ways that this process can be enhanced, but it works, it's stable, and unlike the simple headers and footers that I previously used, these "Master" includes allow me to make huge differences to the existing site with one line of code, or even a single variable.
An example is the width of the site. It was built at 740 pixels for compatibility with 800x600 screen sizes, but was changed to 600 pixels by modifying one "width" variable. Likewise, if I wanted to place a banner rotation or other script somewhere on the top or bottom of the page, I don't need to go and change a ton of stuff, it's just one or two lines of text, on one page!
I hope this series has provided you with some useful information on using includes, and a conceptual approach to building a site with them. Can you think of a way to enhance this approach? Share your comments through the link below!
~ Stephen
