As we're cutting a new release, it would imho be great to include these
changes as well.
Carsten
Felix Meschberger wrote:
Hi,
Am Donnerstag, den 05.06.2008, 15:18 +0200 schrieb Alexander
Klimetschek:
On Thu, Jun 5, 2008 at 2:06 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote:
Given the changes below, I think, we should not release the i18n module
yet with the initial Sling release. Instead we should carefully build
these changes into the module and release as soon as we are ready.
Ok, sounds like the best way to handle this situation. AFAIK there is
only one project using this bundle right now and we have control over
it.
Please, create an issue for these changes.
I will do so once when we have concensus in this thread.
I think we almost have consensus, except for the key thing below ...
6) The sling:key should be optional and only be used if the actual key
(which would typically be the original, eg. english, source string) is
not a valid JCR name. Otherwise the node name should be the key (no
need for generating message1, message2, etc.)
Not sure, whether this is implementable.
If you could provide me with good queries to find messages by key, I
might get convinced. In priniciple, I think it is not a bad idea. But it
must be implementable ;-)
Three solutions come to my mind:
a) Use a sling:key == key OR nodename = escaped(key) (algorithm from
7) query. But I am not sure if this is possible.
not needed, see (c)
b) The query would run use algorithm from 7) below to generate the
non-unique part of the node name and do a jcr:like("Same_name_%"). If
this results in multiple results (eg. Same_name_1, Same_name_2), it
has to manually find the correct one by looping over the result set
and looking at the sling:key properties.
not needed, see (c)
c) Don't load messages one-by-one but have the JcrResourceBundle load
all messages up-front (upon the first call) in-memory. The internal
hash-map would only store the actual keys. Pro: Simpler implementation
and this might be more efficient anyway, since the messages get
cached. Con: Yet another cache...
WDYT?
Actually, we have two queries in the i18n JcrResourceBundle class: One
to get an exact message for a language given its key and one to get all
messages for a language. Currently all key/message mappings are cached
any way, and when the ResourceBundle.getKeys() method is called, all
messages are loaded and cached anyway. So, we just could load these
upfront.
This of course also makes the code leaner, which giving some performance
penalty to the first user of the resource bundle.
The other advantage of loading everything upfront is, that we only need
a single query which does NOT involve quering for the key value.
So, I think, you can create the issue -- and fmeschbe says, he would be
happy to also get a patch ;-)
Thanks and Regards
Felix
--
Carsten Ziegeler
[EMAIL PROTECTED]
