There is only one constant in this line of work: If you thought about it, somebody else has already done it. Nowhere is this rule more evident than in the web design/programming field. Why do I refer to it?
Well, I started this site (more specifically the code that generates this site) on a whim and an afternoon’s coding. I seem to return to it to add content now and again and the limitations of my own code become apparent. While the current format serves my needs it does not serve my wishes. It seems that in my role as client of myself I have turned in the stereotype nightmare of every software engineer: the client who keeps adding requirements with every opportunity. And I can’t complain nor refuse me.
Adding to the wishlist and doing the preliminary planning for the features needed, one thing becomes apparent: There is a need for advanced templating if I’m going to be able to sustain the code.
Content is very clearly separated, in it’s own XML format and the corresponding object hierarchy:
A site has a configuration and sections, each section contains articles. Locally referenced binary files are data.
Simple, sufficient and above all easily extendable (i.e. it’s easy to add subsesctions by adding an aggregation from section to itself).
Where we get mixed up is in the separation of presentation and presentation logic. The solution used thus far was pretty basic.
There are lots (ok, more than one) of small HTML templates with placeholders for the data, i.e.the template for the articles content is:
<div class="title">%title</div><br/>
<div class="content"><br/>
<p>%text</p><br/>
</div>
These templates are then stitched together by the code, i.e. the code that constructs a page is:
#creates the page for an article
def build_article_page(artcl,cfg)
page=page_start(artcl.title,artcl.language)
#add the menu
page<<build_menu(artcl.title,cfg)
#add the static content
page<<article(artcl)
page<<page_end
#return the page
return page
end
each method opens a corresponding template, fills in the data and appends to the result string.
This has various disadvantages, the most obvious being that I have tied the page structure to the code and cannot reorganise my templates without rewriting the code.
Very sloppy, but then again I don’t intend to write another generic CMS system, I only want to generate my own site: fixed design and (mostly – as we have seen) fixed requirements. The goal is not absolute flexibility, it’s sustainability and maintainability of code.
Extending this scheme is cumbersome, insofar as to having to write a template, the template parsing code and the tie-in code for every change I want. Enter the requirement for a template engine.
Ruby (did I mention the site code is in Ruby? I didn’t? shame on me!) offers several template libraries, foremost being RDoc and erb, bundled with the 1.8 version. Using the RDoc engine seemed a little contrived and erb allows you to embed ruby code in the template which goes a little too far for my purposes (yet).
Kwartz and Amrita are the XHTML template solutions that made my short list and I admit I went for Amrita because I find it hard to shift through Makoto Kuwata’s english and because Kwartz is a bit too much for my scale (keep it simple, only change clothes when they don’t fit you anymore).
Sometimes I wish I had taken the time to learn japanese, at least in order to get more into the sense of sentences with absent determinants.
Anyway, moving from custom templating to a template engine is the next step in this site’s evolution. Let’s see if I can get it to work in the next two days.