Site notes: a peek behind the scenes
I didn't do much with my site between 2002 and 2005. Either there was no time or no motivation. Then came the need to make changes.
Unfortunately, the original design was such a mess of frames, HTML, JavaScript and PHP server-side scripts that site-wide alterations would entail a massive amount of repetitive work and risk breaking things I had forgotten existed or how they functioned.
Design + content = bad mix
Before I did anything with content or appearance, I therefore needed to re-think the underlying mechanics.
Separating content from design is a goal of modern Web technologies. This was clearly my problem. Content was too closely associated with the things that make a page look the way it does.
I set about pulling the two apart. My aim was a system where new pages could be added with minimal work, and visual design changes could be accomplished quickly and easily. I also wanted pages whose code is smaller and simpler.
How I did it
I decided that in addition to making better use of Cascading Style Sheets (CSS), there would be a master template containing all the bits common to every page: logo, navigation bar, page footer, certain meta tags and so on.
All my content was stripped from the old pages and put into new files that contain just the words, links, bare-bones HTML tags, plus meta-tags and PHP scripts specific to a page. These files are XML-like, but simpler.
Why not XML?
Because, at the time, I didn't know it very well, and getting the site moving again was urgent. The XML-like character of the page files suited their purpose, but would also make it easy to migrate to pure XML at a later time.
I later learnt XML, and even wrote a parser, but decided that on this site it offers no benefits over what I already have.
Working on the parser taught me to be wary of using XML as a general-purpose default choice for data storage. Its flexible free-form nature, human readability and universal currency bring advantages and compromises. XML is sometimes a good choice, but making that choice involves considering XML's pros and cons alongside other options.
I see people using XML as a core data storage format (as opposed to being an export option from another format) apparently just because XML is trendy and everyone else is using it.
XML is worth considering when criteria such as data interchange and reusability must be satisfied. But, particularly with larger files, be aware that much more background processing is needed than with a less flexible format.
Assembling a page
Weaving together content and template files is a PHP script that builds HTML pages. This runs every time a page is requested from the server.
The template is standard HTML, with a couple of embedded comments to tell the script where to insert content.
The result is that if I want to change the site's design, I only have to upload a new template and/or CSS. Pages served subsequently are automatically re-clothed.
When I want to add a page, I need only work on the content. The presentation is taken care of automatically.
A simple cache
Regenerating pages that haven't changed since last viewed wastes server resources, so the script also manages a simple cache. It saves a copy of each page it produces. A check of the date stamps for template, source page and cached page tells the script whether the saved page is outdated or reusable.
One further feature is that a page can have a list of associated files on which it is dependent. The date stamps of those files are checked along with the standard set. This enables me to update, for example, separate data files for table generator scripts.
The future
Version 1 of my page builder script fulfils the goals I set and has served me well. Top of my wish list for Version 2 is the ability to split a single article source file over several HTML pages by means of embedded page-throw tags.
The script isn't currently available for download, but may be after further refinement and when I get round to documenting it.
