I just merged the xml_content branch to the main CVS trunk. I made some extensive testing to make sure everything works well, but of course it's possible I messed something up so please check it out.

Some minor notes:

• When a story or comment is modified, story.cache.modifytime is now set to the current time (while story.modifytime is only set on major updates) to signal that cached content parts should be re-rendered.
• I managed to fix the problem with setting the createtime of stories we mailed about a few days ago (Tobi and Robert).
• Robert: I kept the underscore separator for form parameter names because they're used us JavaScript property names sometimes, e.g. when checking if content_text is defined in the parameter object, and this wouldn't be so nice to do with colon separator. I don't mind going with colon though, if you prefer that.

I've finished the new database-schema and updated Antville in CVS. Basically the following has changed:

• There are now three SQL-scripts for creating the Antville-database: for mySQL, for Oracle and for hsqldb (the latter is currently outdated because it creates the old db-schema). Due to some special features in mySQL (id-autoincrement and the timestamp-columntype) the Oracle-script will also create a sequence and two triggers (on the table AV_ACCESS). I also included a template for db.properties if you want to use an Oracle-database. (for details reg. the new database-schema, have a look here. There is also a db-patch that will convert an existing mySQL-database to the new schema (see below!)
• some of the protoypes were renamed to match the names of the database-tables: weblog -> site goodie -> file goodiemgr -> filemgr member -> membership membership -> membermgr this also changes the macro-handlers, eg. the macro <% weblog.title %> is now called <% site.title %>. the default-skins have changed too according to this (same with goodie). For consistency-reasons i've also renamed some macros and functions.
• Most of the stuff that 'til now was defined in app.properties can now be defined via a setup-page. Antville will check if it has been setup'ed and redirect you to /manage/setup if not. It's now also possible to change the language of the whole Antville-Installation, to define a "system title" that will be used instead of "Antville" (mostly in page-titles and confirmation mails).
• It's not possible anymore that an admin of a weblog can "degrade" himself to a lower permission-level. this means that there will always be at least one membership with admin-rights.

IMPORTANT: Due to the new database-schema i do not recommend you to update antville now if you are seriously using Antville. If you already have some weblogs in your database they will throw some errors because the macro-handlers have changed. And most likely the skins that are stored in the database will do so too. We will soon come up with some scripts that will do the update of your data. For testing this version of Antville you should use a newly created database.

I hope this update works fine, but if you encounter bugs please report them here in the project log.

today i merged in the changes made in the branch grob_messages into the main trunk in CVS. please give it a try (but remember: this is still part of code-refacturing and therefore should be considered beta!) and report any bugs or suspicious behaviours.

as a follow-up to hannes' timezone-support i changed the way the application-messages of antville are generated. app-messages are now defined in central files (called 'messages_[lang].js', where [lang] should be the two-character-code of the language (e.g. "en", "de" ...). those messages are basically skins and are stored in an object-tree beneath app.data[lang], currently divided in two "classes" of messages: "error" and "confirm". messages can be retrieved using several global functions (in global/objectFunctions.js). variable values are passed to the skins (either one uses a single string which will be embedded instead of the placeholder <% param.value1 %> or an array which values can be referenced using .value1, .value2 and so on).

depending on helmas or antvilles language setting (in server.properties resp. app.properties) or a weblog's language antville tries to retrieve the requested message. if it can't be found, it will retrieve the english version (this is currently hardcoded, but i'll change that within the upcoming antville application setup). right now there are just two languages available: english and german (my spanish is still too bad, not to mention catalan ;-)

i committed the changes into a new branch in CVS called grob_messages. use cvs update -r grob_messages to check out.

please give it a try and post your opinion about it. hope you like it.

I've checked in a patch to weblog/search.hac that escapes single quotes in search strings. This may or may not have been a security problem (if it was, I wasn't able to exloit it). Anyway, antville.org is running the updated code now. This is a temporary patch since I'm currently rewriting the search function to be more flexible, including the capability to search the whole site/server instead of just one weblog.

Finishing timezone support for Antville was pretty painless - all I had to do was make sure that date parsing and formatting are always done through parseTimestamp() and formatTimestamp() functions, which take in account the local weblog's localisation and timezone, if a weblog object is present in the request path. All dates are still stored in local server time. Both parseTimestamp() and formatTimestamp() are in global now, although weblog.formatTimestamp() is still there for backward compatibility - I didn't want to go through all the code - but all it does now is to forward the call to the global formatTimestamp() function.

The fact that the weblog object for date localization is always taken from the request path (i.e. path.weblog) causes one significant change: If an object from one weblog is used from within a page of another weblog or the application root area, the language and timezone from the embedding environment will be used for rendering dates, not those of the object's home weblog. In my opinion this makes sense because with timezone support, dates would not only be rendered in a strange language, but could also be a few hours off, i.e. you'd see dates in different timezones mixed together in one page. However, if this functionality is needed, it would be possible to format dates according to their home weblog by passing either the weblog or the locale and timezone to the formatTimestamp() function.

Finally, I implemented caching of java.text.SimpleDateFormat objects. These things are pretty expensive to create since the format has to be parsed each time. On the other hand, reuse is difficult because the class is not thread safe and would produce broken output if used by multiple threads at the same time. My solution is to cache them in the res.data object, using the format string such as "short", "yyyyMMdd" etc as key. front page rendering is now about 10% faster, and the gain could be even larger for pages with many dates.

Right now, the changes are still in the hns_timezone branch. I'll test some more and eventually merge changes to the main branch if that's ok.

I just commited a patch to CVS to get rid of dual skin managing infrastructure in weblogs: "skinmanager" containing the skins and "skins" doing functional management on them. From now on, everything is contained and managed within the skinmgr prototype. The direct benefit is that some code becomes a bit nicer, but the real reason is to make the skin manager less dependent on its surrounding (I was playing with plugging a skinmanager at antville root level, wich is now possible with a few additional hacks, but it's also possible that somebody might want to plug it into a different application altogether.) Let me know if you encounter any problems (in your local installations - it's not on antville.org yet).

PS: An interesting experiment: update to the newest CVS version and then add

skins = mountpoint(skinmgr)

in root/type.properties. Then invoke URL /skins in your antville root. While the skinmanager itself would work, you'll get errors from the security functions and rendering functions which expect a weblog object to be around. If we can solve these errors (not just in a per-case basis by making root look like weblog, but by defining some standard modes of interaction) we'd be able to get true meaningful modularity, I think.