I remember we had endless discussions on the sequence of finding
properties and I'm not able to recall all of them. I'm not aware of
any changes to the code for quite a while. And as it has been fairly
silent with respect to users asking questions or requesting
functionality, means to me that most users are happy with what we
have. I don't say it can't be improved and it most likely has
ambiguities and bugs as well.
The reason for the Stack order, provided I recall correctly, assume
you have self-contained component with all default properties
required. Next you place the component in your apps, but you want to
change the default properties, than the only place outside the jar is
the any of the parent properties files. Make sense?
To Johans point, I think the current implementation is too inflexible,
it is far to difficult to change/extend/limit the search order easily
if required. IMO this general design problem needs to be fixed.
Juergen
On 11/18/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
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
>
