CMS is a rather awkward abbreviation for a technology that is both simple and important: the means to publish online. I’ve heard of some people’s efforts at writing a generic CMS for Wicket, and while I’m curious what they’ll come up with and applaud anyone’s work towards the common Wicket good, I can’t say I’ve felt the lack of such a beast myself.

A portal to hell

The ongoing enthusiasm for “content management” software reminds me a popular idea in the mid-90s, that Visual Basic was going to eliminate the need for expensive and smelly programmers. Trade magazines suggested that somehow non-programmers could draw crap on the screen and it would fill itself with magically delicious data. It never happened, unfortunately for everyone’s olfactory nerves.

And on the Internet, I’ve noticed that no one wants to visit crappy “portal” sites built from a bunch of crappy pre-fab blocks. No one cares about “news flashes” or “callouts.” And they certainly don’t go for unfashionable site design, a consequence of layouts and module structures assembled months or years prior to CMS deployment.

Your best toolkit for publishing something that people besides the marketing department will want to read is not a set of big blocks, but a set of small ones. You need a solid HTML-only templating system, like Wicket’s. And you need easy access to persistent storage (ahem).

Consider the Databinder recipe book example. It does exactly what it needs to do, with no compromises in its user interface or database schema. Building it in a generic CMS would have taken just as long, introduced a bunch of clumsy bells and whistles, and ultimately produced a cookbook shoehorned into a marketing portal.

The non-CMS

Once you have the precision tools you need, it’s very easy to throw together a content-only site that looks and works exactly as it should. Being of the practice-what-you-preach persuasion, I’ve decided to rewrite Databinder’s home (currently static pages produced by Maven’s mediocre site generator) as a Databinder application.

It’s been fruitful work already. The user-facing side of it is entirely query-cached, so that repeat loads don’t hit the database at all. I’m also setting the last-modified header and allowing browser caching, so performance should be in the static HTML ballpark. It’s not quite ready to take over the root redirect, but you can check out this sneak preview.

I’ll be folding its caching stuff into the recipe book example, and possibly adding a new optimization section to Databinder 101. But I won’t be releasing the source to this new app, because there is nothing clever about putting persisted data on the screen. If there were, it would mean that Databinder wasn’t doing a very good job.

And you know how Databinder gets when you talk trash about its work.