we should first go through it for the given language and then do it for the
default language
But quickly looking at that.
That won't be an easy fix, because the iteration through components is in
Localizer and the iteration over locale/style is in
XxxxStringResourceLoader
My personal opinion about the current resource loading that it does to much,
we support to many cases. It should be simplified.
johan
On 11/18/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Hi all,
I'm writing a chapter on internationalization/ localization, and found
out the message loading works differently from what I expected (and
I'm quite sure how it used to work pre 1.2?).
The first thing I stumbled on was the fact that messages are located
searching from parent to child instead of the inverse. What is the
point of doing that? I would expect something like this to work:
MyPage.properties:
my.property=some value
MyPanel.properties:
my.properties=override
If MyPanel is added to MyPage, currently my.property would resolve to
'some value', while I would expect it to resolve to 'override'.
This patch would fix that:
Index: /Users/eelcohillenius/Documents/workspace/wicket-2.0
/src/main/java/wicket/Localizer.java
===================================================================
--- /Users/eelcohillenius/Documents/workspace/wicket-2.0
/src/main/java/wicket/Localizer.java (revision
476204)
+++ /Users/eelcohillenius/Documents/workspace/wicket-2.0
/src/main/java/wicket/Localizer.java (working
copy)
@@ -325,7 +325,8 @@
// Build the search stack
final List<Class> searchStack = new ArrayList<Class>();
- searchStack.add(component.getClass());
+ Class<? extends Component> componentClass =
component.getClass();
+ searchStack.add(componentClass);
if (!(component instanceof Page))
{
@@ -333,7 +334,8 @@
MarkupContainer container = component.getParent();
while (container != null)
{
- searchStack.add(container.getClass());
+ componentClass = container.getClass();
+ searchStack.add(componentClass);
if (container instanceof Page)
{
break;
@@ -409,7 +411,11 @@
if ((searchStack != null) && (searchStack.size() >
0))
{
// Walk the component hierarchy down from
page to the component
- for (int i = searchStack.size() - 1; (i >=
0) && (string == null); i--)
+ // for (int i = searchStack.size() - 1; (i
>= 0) && (string ==
+ // null); i--)
+ // {
+ int len = searchStack.size();
+ for (int i = 0; (i < len) && (string ==
null); i++)
{
Class clazz =
(Class)searchStack.get(i);
But I'm wondering whether there was a reason to do it starting from
the parent, as treating it like a stack seems to be deliberate.
Another thing I found out is that resolving using inheritance gives up
too quickly in some cases. For example:
[Base.properties]
[Base_nl.properties]
s1=invoer
Foo.properties
s1=input
If Foo extends Base, and you try to get s1 for the Dutch (nl) locale
relative to Foo, it will never actually reach Base_nl.properties but
instead get the value in Foo.properties (the English default in this
case). I think this is wrong too, though the fix might be nasty.
WDYT? Anyone noticed some other unexpected behavior here?
Eelco
