afongen
Sam Buchanan's weblog.

Planning the changes.

While thinking about a redesign for this site, I've also been wrestling with the content management/updating side of things.

On the one hand, as Paul Sowden has pointed out about his own site, the site content is updated much less frequently than it's accessed, so static files make a whole lot of sense. I'd like a system in which each entry can stand alone as an XHTML file, be served up and make sense. Archive groupings can be built from these individual files.

On the other hand, I'm generally not comfortable with systems like GreyMatter and Movable Type, which edit static files but generally require those files to be world-writable. There are ways around that, of course, but I am still drawn by the notion of using an RDMBS instead.

If I store entries in a database, though, I want to be able to pull them out to static X(HT)ML files without a lot of hassle. As I've indicated before, I very much believe that for long-term flexibility, XML is the way to store content. It doesn't matter much to me whether the XML docs are stored on the filesystem or in a database somewhere. I'll likely end up writing my own rather basic system that stores individual entries as XHTML documents in an RDBMS. It's probably not necessary to roll my own, but I feel like it. Good for the soul and all that. As usual, it's just a matter of finding the time.

Then there's the matter of different page elements like navigation menus, the news feed, lists of links, and so on. I use a template system right now so that I don't need to update every page whenever I change or remove one of those sections. The most recent version of each page element is served up every time a page is requested. Each of those sections is actually an XML file that's parsed and converted to XHTML on the fly. Honestly, I'd like to do this with JavaScript instead of PHP/Perl but am concerned about accessibility: do I really want to prevent non-JavaScript-enabled user agents from access to that information? On the other hand, is it really essential content or is it just something extra that's available if you happen to have JavaScript? That's a coward's way out, though, using an argument more suited to effects like rollovers or hierarchical menus than actual content. The response is the same: I will use JavaScript to add those sections to the page but offer an alternative method to access the content, probably on a separate page.

First, though, I've got to push out a new design. Back with that soon.