Website’s content — which goes where?
Yet another blog generator surfaced, called Jekyll. Probably nobody would have noticed, if it wasn’t for GitHub to introduce their GitHub Pages, based on Jekyll. GitHub has been a blogging platform for a while already (see e.g. Homoiconic by Reg), so this seems like making blogging an official feature. Also, this justifies a critical analysis of the concept.
I’ve been following ikiwiki, another site generator, for about half a year now. Actually, it’s a hacker’s dream, blogging with Emacs, storing the whole history in Git, having your site update automagically and being mostly secure because most web-visible content consists of generated static pages. For me, being statical is just a nice add-on, but I really really like the idea of blogging with my $EDITOR instead of some idiotic web-page form (but that’s a completely separate ranting topic). Lack thereof in WordPress is the main reason I’m so lazy about blogging.
However, there is one major flaw, which so far has been exhibited by every RCS-enabled blogging engine I’ve seen: these tools violate MVC. Simple case goes like this: user creates a new blog entry somewhere under posts/2008/12/26/my-blog-post.mdwn, which gets transformed to /posts/2008/12/26/my-blog-post.html by the engine. There might be some derivation, but the principle stands — directory structure in the source is being mapped one-to-one to the web. However, this means that entry’s representation in a URL is directly attached to the content of this entry. Separating concerns, anyone?
Actually, it seems like correct behaviour: put a bunch of content into a storage and let some website generator do its work and present this content to the site visitor. In each blogging system each text is available at several locations: entry’s permalink, month’s overview, tag’s overview, category’s overview, etc. The problem is in our case that a single web-site location for the content is assumed and hard-coded by the author, every other is generated, which is to say the least, inconsistent.
A single blogger can play different roles on his website at the same time: designer, admin, coder, author, editor, usability expert etc. It’s important to remember which role starts when. Putting a text into the system is author’s task, but the editor’s the one to decide where to put it on the website. Depending on situation, there might be several locations, might be just one or even none if content is not to be published until a certain date. But it’s still in the database, it’s its visibility that changes.
Therefore separating concerns in this case requires web-site generation which relies only on content’s metadata and a set of publication rules. The contents of each page on the website could be defined by subroutines returning the entries. For example, if we assume that a list of all articles on a web-page is available (@posts), we could define (pseudo perl code):
- All posts:
"/posts/" => map {$_.summary} sort {$a.date cmp $b.date} @posts - All posts for a certain date:
"/posts/\d{4}/\d{2}/\d{2}/" => map {$_.summary} grep {$_.date ~= "\1/\2/\3"} @posts - An index page:
"/" => grep {$_.category ~= "start" } @posts
In this case, it’s irrelevant how these pages are stored, the engine needs to make sure @posts is available and contains everything from a site.
In this context it’d make sense to define permalink strategy too. Taking an ID of an article as its permalink, one could define $permalink = sub { "/id/" . $_.id } to be a canonical generator for permalinks for each article.
What happens if permalinks change? Consider permalinks containing slugs (many people like them). Slugs are mostly auto-generated, so that permalink based off a slug will change if you update the title of your blog post. If it doesn’t, it might not be appropriate for the post anymore and thus misleading for the visitors. You could also change you permalink strategy completely, for whatever reason. If your writing is somehow relevant and linked to on the net, you’ll break a lot of links on other websites. Nobody wants that, but everyone does that every now and then.
If we however additionally save a URL and the subroutine which has been used for routing each time then we’d have a redirection permalink list. It could be checked by default if no current page definition matched. This way for each part of your web-site which has been visited at least once, you’d have a routing available and thus, these URLs would not die. This could help our permalinks be at least a little bit more permanent.
So to sum it up: in a perfect world we’d be putting our blog entries under version control in an arbitrary order, making sure our metadata is correct. A rule set would define how the website is built together based on this metadata. Permalinks would not die at the wave of a hand, defining additional views and URL patterns would be as simple as adding a single text line to a file. A couple of HTML templates would round up this whole stuff. A hacker’s ranting would be a little bit easier in a long run…