The Jackal Rants

The BookInformation extension is more or less done; at least, the first incarnation is. Checked it into Subversion, although it’s without documentation right now and doesn’t support anything other than Amazon Web Services.

I’ve put it live on my test wiki.

Oh, and thanks to Dirk, Raymond, and Niklas for prompt translations for Dutch, German and Finnish.

It’s extension writing time, again – a new one, BookInformation is en route soonish. It will allow site owners to configure web services such as the Amazon Web Services set that can be used to perform basic informational queries when users are accessing Special:Booksources.

The whole thing’s nice and object-oriented, and is based around the concept of a “book information driver”, which is a class implementing a straightforward interface spec, so writing drivers to handle providers other than Amazon will be relatively simple.

This probably won’t make it live on Wikipedia or any Wikimedia wiki, simply because we’d have to find a provider who would allow us to access their web service at a relatively high rate. There’s built-in caching of responses per-ISBN, but it wouldn’t choke the Wikipedian influx enough for quite some time.

I’ve just released version 1.1 of the RandomImage extension; the quick and dirty parser hook extension which tries to bring a bit of spontaneous dynamic content generation to pages.

The new version introduces a new configuration setting; $wgRandomImageNoCache, which defaults to being off. When set to true, however, it disables the parser cache for pages using the extension, which means true randomness. This could be a performance bitch for large sites with huge numbers of images and on large pages where the formatting alone should have been cached. Double-edged sword.

• RandomImage Extension on MediaWiki.org
• Extension code in Wikimedia Subversion
• README file

I altered a bug report earlier; standard stuff, made the summary a little more comprehensible, tweaked the product and component, etc. etc. Nothing particularly amazing about that.

About ten minutes later, I received a polite and friendly email from the guy who posted the report…seems he got hopeful when he saw it being modified, but dropped a little when it wasn’t resolved.

The report’s been open for about half a year, and nothing done on that front; but the user, unlike many we see today (unfortunately), was polite, and patient, and didn’t bitch.

I committed the fix half an hour later and remembered why it is that I do this.

All right, I’ve committed what should be all of the main detection regexes for the FormatDates extension now, so it’s time to devise a test strategy for the code.

Avar’s new TAP-based thing is nice, but isn’t really easy to use with something like this, because a lot of MediaWiki is hideously interdependent – encapsulation is almost a dirty word. Sadly, this applies especially to the Language classes, upon which the DateParser class has a dependence.

I suspect I’ll end up using a light variant of the parser tester to do this…to be honest, the more irritating part’s going to be writing the test cases themselves.

Latest version’s up on the test wiki, as usual.

Dear lord, stuff takes absolutely ages these days. This morning, I coded up a quick little enhancement no-one else had even thought of.

I committed it five minutes ago.

What happened? Well, it’s been one of those days, y’know? Discussions aplenty, arguing all over the place, and lots of users in #mediawiki taking advantage of direct access to front-line support. I got completely distracted every time I went to test it. Still, it’s here now.

Oh, what was it? Look at your query pages.

After some issues with the hosting provider I use, PHP 5 is all sorted out again, and I can reinstall MediaWiki.

The new test wiki is at http://wiki.anubite.co.uk and is running a more-or-less bleeding-edge version of MediaWiki trunk, so it’s 1.9 alpha right now. I’ve installed a bunch of the extensions I’ve authored on there, including the under-development FormatDates extension (see previous posts), so interested parties can mess about with it while I work on it.

Incidentally, I checked FormatDates into the Subversion repository this morning.

Well, as is typical with these sorts of things, I didn’t get a lot done on the shiny new date reformatting class following the last post; damn festive season, gets in the way of everything. Still, I managed to make some significant progress yesterday evening, and this morning.

I realised that a major problem occurring was that full dates were being happily refactored, but corrupted when partial dates were processed.

For example, “20 January 2006″ would be happily refactored to “January 20, 2006″, for instance. Unfortunately, when it came time to match against stuff like “month, day” (no year), this would pick up the first part and…cause a horrible mess.

I’ve combated this using a simple but hopefully fast and adequate placeholder system – once a date is successfully refactored, it is stashed in memory, and a placeholder string is assigned to it. This string is composed of the concatenated values “DATEPARSER_”, a hash of the original chunk of text itself, and then “_X”, where X is just a numerical index identifying the result text. This is rapidly switched back in place when all the actual date refactoring has been accomplished.

After dealing with a misplaced $this which was causing the new FormattableDate class to not actually load any information, everything started working! I’ve implemented a few more “letters” – that is, identifiers for a particular part of a date (see http://www.php.net/manual/en/function.date.php), and all the destination formats are now possible.

What next? All I have to do is write a couple more regular expressions to pick up the last remaining possible formats, and then I can move onto testing. And for that, I plan to use Avar’s shiny new testing framework…