Blog Archive - part one: switching to multiple pages

Since there are now more blog entries than slots on the front page (5), I've added a mechanism to access posts by id number. Rather than add this as a switch on the front page (using query-strings in the URL) I've implemented it as a seperate page.

This then changes the site from a single-page site to a multi-page site, and makes a good point at which to decide a multi-page strategy.
There are various options here;

1) Recode each page from scratch
2) Copy the first page into a new file and edit that
3) Use header and footer files and include them in each page
4) Use a template system and set the content in each file

These all have various pros and cons.
1) certainly allows variety in page design, but is otherwise horribly inefficient - there is no code re-use, and changing the site design at a later date would be a very boring task.

2) isn't much better - it may actually be the quickest way to create this second page, but again future site design changes require that each page be edited (even if we were to use a single, shared CSS file)

3) is much better, and is the system I've used on most of my sites previously - see for example - each file start with the PHP code:
<?php include('top.php'); ?> and ends with
<?php include('tail.php'); ?>.
This way, if I want to change the site design later, I only have two files to edit to adjust the whole site. But it only gives me access to the start and end of the page - it's not all that flexible.

4) instead of adding the design to a content page, this adds the content to a design page, and is the technique I've used here. Page elements are generated and then stored in PHP variables (in this case, elements of the array '$template', and the last line of each active page calls in the template: include('templates/base.php');
The template is a simple PHP script, consisting of the standard HTML for the page layout with a few lines like <?php print($template['centercol']); ?> to display the generated code elements.

One problem with this approach is that nothing is output until all of the code has been executed, so it's important that the code executes quickly and that all errors output meaningful information into the template. Script timeouts and empty pages are no use to anyone, so it's important that debugging is done carefully. However, all of these are good practice to use anyway, so they're not really a constraint.

In addition, this templating technique is a good precursor to generating self-caching pages - a technique I'll touch on in a later entry.
Posted by parsingphase, 2004-04-09 14:31

Anonymous user



Contact Richard