Re: Possible bug in FormComponent$MessageSource regarding resource string lookups
Done: WICKET-1888 igor.vaynberg wrote: > > request for enhancement. add it to our jria. > > -igor > > -- View this message in context: http://www.nabble.com/Possible-bug-in-FormComponent%24MessageSource-regarding-resource-string-lookups-tp19951394p20130775.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]
Re: Possible bug in FormComponent$MessageSource regarding resource string lookups
request for enhancement. add it to our jria.
-igor
On Mon, Oct 13, 2008 at 8:32 AM, Christian Oldiges <[EMAIL PROTECTED]> wrote:
>
> 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
>>> 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"
Re: Possible bug in FormComponent$MessageSource regarding resource string lookups
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
>> 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
Re: Possible bug in FormComponent$MessageSource regarding resource string lookups
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
>> 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
> wick
Re: Possible bug in FormComponent$MessageSource regarding resource string lookups
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
> 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
Re: Possible bug in FormComponent$MessageSource regarding resource string lookups
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
> 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
Possible bug in FormComponent$MessageSource regarding resource string lookups
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
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]
