just for the records: i made a huge step forward in rewriting robert's cool image_macro (here's the code in a cvs branch of antville, third function from top).

the features of thumbnail_macro() and imageurl_macro() are now included by handing over param.as = "thumbnail" or param.as = "url". well, to be honest, param.as = "popup" does the job of the thumbnail macro, while param.as = "thumbnail" does almost the same just without popping up a new window using javascript... (good?)

moreover, i started to modify some of the global renderSomething() functions: the problem was that they are hardly re-usable due to many res.writes in the code. so i renamed these functions to renderSomethingAsString() and replaced the direct output by building a string and returning it in the end. then, i added new functions with the old name as wrappers to directly write out the result of the --AsString() functions again. while it sounds complicated here, i think it becomes quite clear when you think of renderSkin and renderSkinAsString...

is that a way to go? would you support this code structure?

I spent part of last night messing around with localization issues of Antville. Here's what I found.

• Apache/Tomcat/Helma already handles Unicode nicely. That is, if we set charset to UTF-8 in Helma, the only place where it breaks in our current setup is MySQL, which won't support Unicode for a few years to come, it seems (it's promised for 4.1, and right now 4.0, the complete rewrite of MySQL, is still regarded as unstable). So I got really angry at MySQL and promised myself to investigate into alternatives like PostgreSQL, which has no problems with Unicode. Having one Antville server running capable of handling any character set on earth would be a thing of beauty!
• Antclick will infact support Unicode from the next release on. Hsqldb handles Unicode nicely, and I ripped out a little part of Tomcat parameter parsing and plugged it into our embedded web server. I now have a fully Unicode capable Antville running on my iBook (limited on the display side by what my Mac OS X supports of international charsets e.g. Japanese and Chinese works, but not Arabic. So far the only platform with close to complete charset support out of the box I've seen is Linux)
• I implemented support for setting the timezone for weblogs. That is, by setting a timezone in the weblog preferences, times will not only be displayed in the local language, but also with the right timezone offset, e.g. page that was created at noon Vienna time may be displayed as 8 PM Tokyo time. I still haven't updated the database scheme (WEBLOG table needs a varchar(32) field called timezone/TIMEZONE), but I commited the code into branch called hns_timezone of apps/antville/weblog. It works even without the db patch (although weblogs won't remember the timezone after restart), so feel free to check it out using cvs update -r hns_timezone weblog from within the antville app directory. The reason I checked it into a separate branch was that a) I wasn't sure if this functionality is desired, b) it's still buggy/uncomplete especially in regard to weblog days/dates, and c) it poses some new questions we have to solve before deploying. One is that timezones will currently be used to display weblog lists on the antville root area, which will be confusing, because although weblogs will be listed in the right order, dates will seemingly jump back and forward in random fashion. I think that dates in supra-weblog lists should always be displayed in the same timezone, which could be the server timezone or even a per-user settable time zone, which wouldn't be hard to do. Whatever we do, it is probably a good idea to provide a version of renderTimestamp() which could be called with java.util.Locale and java.util.TimeZone parameters and would thus be independent of the weblog prototype and could thus be placed in global.

Please let me know what you think. I think I'll update this posting later with a few juicy screenshots ;-)