A while back I set up a category for tracking my InfoWorld columns and stories. It's a handy feature of Radio (and of other blogging tools, such as Movable Type) -- just pick your category names, and tag one or more of these names onto an item to assign it to one or more categories. As always, though, this little exercise in content management wound up being trickier than I'd planned.
When I created my InfoWorld category back in October, I populated it with a bunch of URLs for everything up to that point. I didn't want to dump all this to my homepage, but fortunately a bug that had prevented category-only posting had been fixed, so that was no longer a problem. Great! That meant I could subtly introduce the new feature by just adding a link to my lefthand navbar.
It was a little odd that all the entries appeared to be Oct 7 2002 rather than their real issue dates, but OK, I could live with that. It made me realize, though, that adjusting date order wouldn't be too easy. Even if I went through and tweaked the dates in the database, Radio processes items in numerical order by posting. It would take more intervention than I have stomach for to overcome that numerical bias.
There was one unintended consequence, though. My page that lists all items in the blog, driven by a storyList script, listed all these Oct 7 2002 items, and that seemed like overkill. So I adapted it like so:
if ( t.flNotOnHomePage == false )
{...}
to exclude category-only postings.
That worked fine for a while, but recently when somebody asked for a link to a story, I noticed that I couldn't find it. Why not? Oh, of course. Categories, like the home page, display a fixed number of days' worth of items. I use the default: seven days. There were a lot of items for Oct 7 2002, but once I'd added entries on six subsequent days, older items began to fall off the event horizon.
Is there a name for the kind breakage that occurs when unchanged code is confronted by more or different data than you were expecting?
The items-per-page setting is systemwide, so bumping it up for categories would make the homepage unwieldy. In any case, a really long category page would be unwieldy for the same reason. So I decided to use a variant of the storyList macro to enumerate just the titles and links of items in a category. Here is that other macro. To make it run automatically, I followed the same technique as described here -- namely, call the macro from a story, and arrange for a system agent to touch that story when an item is published. That forces the story to regenerate, call the macro, and upstream. In order to remember how to do that, I had to search my own blog, which I suppose is both an indictment and a testimonial.
There was one more unintended consequence to deal with. Radio distinguishes between the display name of a category and its filename. For example, the display name of one of my categories is "Web Services" but the filename is "webServices." "InfoWorld" becomes "infoworld." (This scenario of course sets you up for sneaky NT-versus-Unix gotcha: it works on NT because NT is case-insensitive, but fails on Unix which isn't. For that reason, I always recommend testing static namespaces on Unix. Was Windows' case-insensitivity supposed to be a time-saving feature?)
The script, when enumerating postings, needs to find a category-posted item by its display name. But when it forms the URL of the item, it needs to use the filename. So I had to replicate that logic. It's in system.verbs.builtins,radio.weblog.newCategory, which I guess is part of Radio's lizard brain. I found the code, and simplified it a bit using a regular-expression search-and-replace -- something the lizard brain probably didn't know about.
All's well that ends well. Here's the new version of the InfoWorld category, also linked to from the navbar. I haven't propagated this technique to my other categories yet because, frankly, I'm wondering if this posting will bring a better solution to light.
These things are, as I said, always trickier than you expect. Content management systems try to make reasonable assumptions about the display of time-ordered and categorized data, but when the relationships between those two evolve, as they inevitably do, assumptions break down. Tools that would make it easier for users to do wholesale recategorization or reordering of data are rarely available, for the very good reason that they are hard to create. My guess is that Radio and MT probably hit the sweet spot. They deliver enough categorization and sorting to satisfy most users. Doing more would entail complexity and effort that most users would rather avoid. If you really want to, though, the code's open and you can find a way.
Former URL: http://weblog.infoworld.com/udell/2002/12/09.html#a533