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
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
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
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
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
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]
