Hm, but then the JavaDoc for ComponentStringResourceLoader needs to be
updated, because the following example taken from that JavaDoc clearly
states it will try to lookup "Required" in the "input1.properties" file:



> In addition to the above search order, each key will be pre-pended with
> the relative path of the current component related to the component that
> is being searched. E.g. assume a component hierarchy like
> page1.form1.input1 and your are requesting a key named 'Required'. Wicket
> will search the property in the following order:
> 
>         page1.properties => form1.input1.Required
>         page1.properties => Required
>         form1.properties => input1.Required
>         form1.properties => Required
>         input1.properties => Required
>         myApplication.properties => page1.form1.input1.Required
>         myApplication.properties => Required
> 
 
This would work just fine, once the 2nd getString call gets the
formComponent itself, but not its parent as a parameter.

Eh, what is an "rfe"? Request for Extension?



igor.vaynberg wrote:
> 
> first thing to get is that each getstring() traverses the hierarchy.
> so first we try with id and then without just in case the user forgot.
> 
> the problem here is that formcomponents do not provide their own
> resource bundles. you need to add an rfe to support this.
> traditionally only top-level markup containers provide bundles, eg
> page and panel.
> 
> -igor
> 
> On Mon, Oct 13, 2008 at 2:28 AM, Christian Oldiges <[EMAIL PROTECTED]>
> wrote:
>>
>> Hello!
>>
>> First here is my setup and the situation in which I discovered the
>> problem
>> which might be a bug in FormComponent$MessageSource:
>>
>> I am using v1.3.4 and I have a problem placing a resource string for a
>> customized subclass of CheckBox.
>>
>> My component tree looks like this:
>>
>> page.form.main.data
>>
>> -page is a subclass of WebPage, the page.html file contains several
>> <wicket:fragment> tags which are used to create a wizard style UI
>> -form is a Form object
>> -main is a Fragment object
>> -data is a customized subclass of CheckBox
>>
>> Now my problem:
>>
>> We have created the CheckBox subclass because it contains spezialized
>> behaviour and we need customized error messages, especially for the case
>> when the checkbox is NOT marked by the user when the form is submitted.
>>
>> For that reason we created a "data.xml" next to the "data.class" which is
>> supposed to contain the error messages. Now, the data component marks
>> itself
>> as required and thus triggers a "Required" error resource key lookup upon
>> form validation when the checkbox wasnt checked.
>>
>> I was surprised to find that the "Required" key is never ever tried on
>> the
>> "data.xml" resource file, so I fired up the debugger to check out whats
>> happening and I think the problem is located in
>>
>> FormComponent$MessageSource.getMessage(String key):
>>
>> --------------------------------------------------------------------------------------
>>                public String getMessage(String key)
>>                {
>>                        final FormComponent formComponent =
>> FormComponent.this;
>>
>>                        // retrieve prefix that will be used to construct
>> message keys
>>                        String prefix =
>> formComponent.getValidatorKeyPrefix();
>>                        if (Strings.isEmpty(prefix))
>>                        {
>>                                prefix = "";
>>                        }
>>
>>                        final Localizer localizer =
>> formComponent.getLocalizer();
>>
>>                        String resource = prefix + getId() + "." + key;
>>
>>                        // First use the parent for resolving so that
>>                        // form1.textfield1.Required can be used.
>>
>>                        // Note: It is important that the default value of
>> "" is provided
>>                        // to getString() not to throw a
>> MissingResourceException or to
>>                        // return a default string like "[Warning: String
>> ..."
>>                        String message = getString(localizer, resource,
>> formComponent.getParent());
>>
>>                        // If not found, than ...
>>                        if (Strings.isEmpty(message))
>>                        {
>>                                // Try a variation of the resource key
>>
>>                                resource = prefix + key;
>>
>>                                message = getString(localizer, resource,
>> formComponent.getParent());
>>                        }
>> --------------------------------------------------------------------------------------
>>
>> This method is called with key="Required" on the instance belonging to
>> the
>> "data" FormComponent.
>>
>> At first the id of the FormComponent is prefixed and getString() is
>> called
>> for the parent of the FormComponent. This would be "data.Required" and
>> the
>> component would be the "main" Fragment. That call doesnt return any
>> useful
>> value, which is expected.
>>
>> Now, the second call of the getString() method doesnt include any
>> component
>> id anymore in the resource key, so it is "Required" and is called again
>> for
>> the parent of the FormComponent. The getString() at some point gets into
>> the
>> ComponentStringResourceLoader class to the
>> loadStringResource(component,key)
>> method.
>>
>> key = "Required" and component is again the "main" Fragment and that is
>> the
>> problem IMO.
>>
>> The component stack created in loadStringResource contains:
>>
>> "page", "form" and "main" but NOT the "data" component, so the key
>> "Required" is never tried on the resource file "data.xml".
>>
>> If the second getString call
>>
>>                                message = getString(localizer, resource,
>> formComponent.getParent());
>>
>> were changed like this:
>>
>>                                message = getString(localizer, resource,
>> formComponent);
>>
>> the component stack would go all the way down to the component itself and
>> would not stop at the parent.
>>
>>
>> Is this a bug or am I missing something regarding the lookup mechanism???
>>
>>
>>
>> BTW: Great job on the WiA book!!!
>> --
>> View this message in context:
>> http://www.nabble.com/Possible-bug-in-FormComponent%24MessageSource-regarding-resource-string-lookups-tp19951394p19951394.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Possible-bug-in-FormComponent%24MessageSource-regarding-resource-string-lookups-tp19951394p19957156.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to