Hi!
Wicket also supports ".xml" files instead of ".properties", so that is not
the problem.
I was able to follow Wicket trying both "X.properties" and "X.xml" for any
location.
So, that is not the problem.
Newgro wrote:
>
> Am Montag, 13. Oktober 2008 11:28:07 schrieb Christian Oldiges:
>> 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!!!
>
> Small question for understanding: Did you set your own localizer? AFAIK
> wicket
> uses property files for localization and if it finds no file on the
> appropriate place it goes up the component hirarchie. So you would need a
> Data.properties file with the strings in it. Maybe im missed something.
>
> Cheers
> Per
>
> ---------------------------------------------------------------------
> 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-tp19951394p19957041.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]
