Hi,
Am Dienstag, den 10.06.2008, 17:06 +0200 schrieb Carsten Ziegeler:
> As we're cutting a new release, it would imho be great to include these
> changes as well.
That would be good. Not sure, whether we get the code ready by then ...
Regards
Felix
>
> 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
> >
> >
>
>
