Using page template skins with server side includes
Here is a live example of how Loosely Coupled uses the template framework I wrote about last week. I've just created a new archive section for the Loosely Coupled weblog, consisting of a separate page for each month (for example, May 2002). That's eight pages already, so it would have been a content management disaster in the making without some kind of template system. As an experiment (and also a simple demonstration of how it works) I've implemented this using SSI (server side includes).
The way it works is that each page is stored as six separate files, which the server combines together whenever a visitor clicks on the URL for the page. Only one of the files contains the specific content for that individual page the other five are the same for every page. So any change I make to those five files, for instance amending a menu bar or updating an image, instantly takes effect on every page that uses them a much more appealing prospect than editing every page individually.
Most good shared hosting services will offer SSI as standard, although many of them won't offer any technical support, so it's wise not to try anything more complicated than simple file includes like the ones in this example. If you want more functionality, you're better off using PHP, for which there's a whole ecosystem of support and advice. One other thing to bear in mind is that, whether you use SSI, PHP or any other technology, having your server build the page for every visitor imposes a performance hit, so if you expect big traffic peaks, it's best avoided for really popular pages, such as your home page.
So that your server knows to use SSI to build the page, you need to name the page with ".shtml" as the suffix rather than just ".html" or ".htm". You can choose any suffix you like for the include files (unless you want them in turn to call other includes or functions, in which case they'll need an 'shtml' or 'php' suffix as appropriate). Then you place an include command at each point in the .shmtl file where you want to insert the contents of an include file, like this: <!--#include virtual="/img/skin_a.txt"--> (for more discussion of SSI, see this handy online guide from BigNoseBird.com).
Four of my five include files make up the elements that surround the core content area on each individual page. These elements are often referred to as the 'skin' of a website, since they create the familiar appearance that visitors recognise on every page:
The masthead is the horizontal strip across the top of the page containing the logo and space for a banner ad. This is contained in my include file skin_a.txt
The action bar is the next horizontal strip of the page, contained in skin_b.txt
Next comes the sidebar, which runs down the left-hand side of the content area. It is stored in skin_c.txt
The footer completes the page, coming after the content. This is stored in skin_f.txt
You may have noticed from clicking on the links that, as individual files, they don't all display with the correct formatting or layout. That's because a) they need the stylesheet information that's kept in the <head> section of the .shtml file and b) they only fall into the correct layout when they interact with each other. Here's the code that they would fit into to create a complete, properly formatted page:
<head><title>Loosely Coupled sample page</title>
<link rel="stylesheet" type="text/css"
<!-- BEGIN CONTENT -->
[variable page content goes here
(usually with a margin or padding of 8 pixels)]
<!-- END CONTENT -->
The design for the archive pages has one other include file, which slots inside the content area to provide a consistent right-hand sidebar. I haven't shown sample code for this as I'd like to explain some of its other features later on, in a separate posting. Meanwhile, you can see it in action on the May 2002 archive page, or any other monthly archive page listed in the archive index.
A small revision to Pro2rss makes some small cosmetic improvements:
The main change pares off truncated words and characters from the end of the item description field. Previously the description was a fixed 120 characters in length, wihch meant that frequently it ended in the middle of a word, leaving a truncated word or character at the end of the line. The new version adds a line of code that searches back from the end of the field to find the first blank space, ensuring that descriptions end either with a complete word or a punctuation mark.
The form input field is now automatically prefilled with "http://", saving users from having to type this in when entering a URL manually
The version number has been updated from 0.90 to 0.95. Intervening numbers have been skipped to avoid confusion with popular RSS revision numbers.
The new code was published yesterday (May 29th).
posted by Phil 5:55 AM (GMT)
| comments |
Building a website using plug-in online services: the Loosely Coupled experience