Hi again, and sorry for the short answer earlier.
I feel the following requires some extra comment on my part:
On 14-04-28 02:53 AM, mck wrote:
>- check if somehow Tiles rely on the file name matching the locale name exactly. In
that case, the "closest
>available locale" solution would be a problem in itself. I'd like especially
to look for calls to PostfixedApplicationResource(String,Locale).
Anywhere you look for a resource and manually specify the locale then
the underscore in the resource name has no meaning.
I understand your concern of the mismatch between a manually specified
locale in one place and then a lookup and closest match in another
place, but i cannot see where this would be done or in what way it's a
problem.
I'm thinking of the following hypothetical use case. Please note that
I'm not entirely sure if this is a real use case, or if it will be in
the future, and anyway it would not work on req-1.0.3, so 1.0.4 improves
on things here and deserves to be released.
WEB-INF/tiles-defs_en_GB.xml
Suppose for some reason, the system decides that en_GB is a valid
locale, but should actually be called en_UK as the closest available.
I'm afraid that the following could occur:
- when a request arrives with locale=en_UK, it doesn't find the en_GB
file because the locale name doesn't match, therefore the file is not
read and the tiles-definition is not found.
- when a request arrives with locale=en_GB, it finds the file and we
build a PostfixedApplicationResource with basename=tiles-def and
locale=en_GB. But when we try and read the file, the locale has been
normalized into en_UK (closest available) and the file actually cannot
be found.
So in the end, that might invalidate the "closest" strategy.
But I couldn't think of an actual locale that would behave that way, so
I'll raise the issue again when I encounter it, and we can address it at
that time. Anyway there's an easy workaround :)
Thanks again for your good work and sorry for the delay.
+1 GA
