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]