[
https://issues.apache.org/jira/browse/SLING-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770902#action_12770902
]
Alexander Klimetschek edited comment on SLING-1131 at 10/28/09 11:54 AM:
-------------------------------------------------------------------------
> the key went away
Because the key is not mandatory (for quite a while), because if it is not
present, the node name is used (that's why I added [...@sling:message] to fetch
only all nodes that have at least that required property set).
In my (manual) tests it worked fine, albeit as you note it now, I wonder why
the /@sling:message was necessary to get the property, but a missing
/@sling:key does work somehow. I think we could change the code to use a
NodeIterator for the results (or Resource iterator when the resource query api
is used) and not use the IMHO somewhat awkward row iterator JCR result.
I will try to write a test case and verify it, albeit that involves the
repository and thus needs a bit more effort.
was (Author: alexander.klimetschek):
> the key went away
Because the key is not mandatory (for quite a while), because if it is not
present, the node name is not used (that's why I added [...@sling:message] only
to fetch only all nodes that have at least that required property set).
In my (manual) tests it worked fine, albeit as you note it now, I wonder why
the /@sling:message was necessary to get the property, but a missing
/@sling:key does not work. I think we should change the code to use a
NodeIterator for the results (or Resource iterator when the resource query api
is used) and not use the IMHO somewhat awkward row iterator JCR result.
I will try to write a test case and verify it, albeit that involves the
repository and thus needs a bit more effort.
> i18n: do not enforce a flat node hierarchy below mix:language
> -------------------------------------------------------------
>
> Key: SLING-1131
> URL: https://issues.apache.org/jira/browse/SLING-1131
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: I18n 2.0.2
> Reporter: Alexander Klimetschek
> Priority: Minor
> Fix For: I18n 2.0.2
>
> Attachments: SLING-1131.patch
>
>
> Currently the search for translations enforces a flat hierarchy below the
> mix:language node (that eg. says 'de' for the translation language) for the
> sling:Message nodes that hold the single translations. If you have many
> translations, eg. thousands, the flat hierarchy can get slow in Jackrabbit,
> so it would be good to support a nested hierarchy as well.
> The change boils down to the query that is done. Currently it looks like this
> (eg. for fetching all translations for 'de'):
> //element(*,mix:language)[...@jcr:language='de']/*/(@sling:key|@sling:message)
> It should introduce a descendant-or-self step:
> //element(*,mix:language)[...@jcr:language='de']//*/(@sling:key|@sling:message)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
