+1 I like the dictionary approach better as it reduces the amount of complex queries.
for backward compatibility the resource bundle provider should initially do a query for the new dictionaries and if found, go into 'dictionary' mode. if not, it would fall back to the "old" mix:language approach. to force loading old mix:language bundles could also be enabled with an osgi config. regards, toby On Tue, Dec 17, 2013 at 3:47 PM, Alexander Klimetschek <[email protected]> wrote: > On 17.12.2013, at 14:05, Tobias Bocanegra <[email protected]> wrote: > >> I was looking at SLING-2881 [0] and reading the docu at [1]. the i18n >> code has 1 queries, one is: >> >> 1) //element(*,mix:language) > > Unfortunately this is too broad, mix:language can be many nodes, depending on > the application. That's why we effectively are using the query below only > which makes it more specific again by looking at mix:language nodes that have > a sling:Message node. > > The mistake we probably made was to not introduce a "dictionary" base node > type. The problem manifests in the observation which gets triggered on > mix:language and is too broad (SLING-2881). Although I already made a > proposal how we can solve SLING-2881 without having to change the content > structure (see issue). > >> 2) >> //element(*,mix:language)[@jcr:language='en']//element(*,sling:Message)[@sling:message]/(@sling:key|@sling:message) >> >> the first one is to find all language bundle roots, and the 2nd is >> used to actually load all messages for 1 bundle. I suggest to replace >> the second one by a manual traversal, since all messages are usually >> just directly below the language nodes. > > Yes, it was just a bit simpler to implement using a query, since it also > needs to support deep structures (we used them earlier, so sling i18n > supports it). But even for that, a traversal using the > javax.jcr.util.TraversingItemVisitor should be trivial. > > However, we might be iterating way too much if we start on all mix:language > nodes. So I am not sure if we have to solve the performance of this query. If > we fix the observation, this query will run only whenever a "dictionary" is > updated or when the system starts. Updating dictionaries only happens very > rarely in applications. > > Cheers, > Alex
