You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Alexander Klimetschek (JIRA)" <ji...@apache.org> on 2009/10/28 12:55:59 UTC
[jira] Issue Comment Edited: (SLING-1131) i18n: do not enforce a
flat node hierarchy below mix:language
[ 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.