Hi Sergiu,
On Feb 28, 2007, at 1:38 AM, Sergiu Dumitriu wrote:
Hi,
I looked today over the XWikiMessageTool class, and I must say that
I'm not quite satisfied with it.
Me neither.
First, there was XWIKI-919, which I implemented. OK, I understand
that files stored on disk should be charset independent, so only
ASCII characters are supported by the ResourceBundle class
(jvm) .But, when I can edit a wiki document for storing bundles, I
expect it to accept all the characters the wiki supports (in my
case, it was an UTF8 instance). I had some troubles fixing this,
since the JavaDoc says that bundles accepts only ASCII characters,
but it understands and parses unicode references ( \u0123 ). Maybe
I did something wrong, but doing content.replaceAll("\u0139", "\
\u0139") resulted in the string u0139 being displayed in the page.
So I had to trick it into believing that the component bytes of the
encoding are ASCII characters and manually restore the multibyte
chars.
Second, I don't like the fact that XWIKI-921 was not already
implemented.
+1 for it.
Third, I don't like the cache refresh mechanism. It retrieves the
XWikiProperties->documentBundles property for each request, and It
retrieves the bundle documents for every request and checks if it
must be refreshed or not. Why isn't the com.xpn.xwiki.notify
package used? It allows registering callback handlers for specific
document changes. How I see it:
- at startup, register a handler for XWiki.XWikiPreferences (so
that we know when the documentBundles property might change).
- remember the list of document bundles, don't ask it for each request
- also register handlers for the current bundle documents and load
the strings from these documents
- when XWikiPreferences is changed, if the documentBundle property
is also changed, remove the unused bundles and build the new ones
- when a undle document (or a translation for it) is changed,
rebuild the bundle for that document
This should speedup the code a bit, it makes use of a nice, but
mostly unknown feature, it doesn't log an error for each request
when a specified document is not found in the wiki, and it doesn't
require so many variables (previousDates, docsToRefresh).
Fourth, as I said above, if a document is specified in the
documentBundles property, but it does not exist in the wiki, for
each $msg.get call an error is logged. And there are a lot of calls
for each request.
Now, in my opinion this is a nice way to get in the core of XWiki
for a newcomer, so does anybody want to write the changes I
mentioned? Also, this is a good occasion to document the event
notification mechanism, in JavaDoc and on
www.xwiki.org
Apparently nobody is interested to get into the core :(
I have started looking at the notification mechanism. It's really
hard to read and understand (especially as some methods are wrongly
named like notify() which is not about doing any notification but
rather being notified!). It looks way too convoluted but I'll try to
doc it and use it in the XWikiMessageTool as I'm making changes to it.
Thanks
-Vincent