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.
>> 2) Not sure for which use cases the sling:basename propert is needed.
>
> This is to support getting a subset of all messages and is comparable in
> some sense to the basename argument of the
> ResourceBundle.getResourceBundle(String, Locale) method. It is used to
> implement the SlingHttpServletRequest.getResourceBundle(String, Locale)
> method.
Ok, makes sense. The property would then be optional.
> but have sling:MessageBundle extend nt:hierarchyNode to be able to place
> such bundles below nt:folder.
+1
>> 4) sling:Message can be a node type, I don't see the case where one
>> wants to mix it with an existing node type structure and needs a
>> mixin. sling:MessageEntry can be removed then.
>>
>> 5) Not sure about the nt:hierarchyNode inheritance for
>> sling:Message(Entry) - do we need it?
>
> If sling:Message are only required (and supported) to be children of a
> sling:MessageBundle node, I am fine with removing that. Instead the
> sling:MessageBundle should extend nt:hierarchyNode (see above).
Yes.
>> 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.
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.
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?
Regards,
Alex
--
Alexander Klimetschek
[EMAIL PROTECTED]
