ListItem partakes in stringresource key generation, resulting in
formName.repeaterName.0.fieldName like keys.
-------------------------------------------------------------------------------------------------------------
Key: WICKET-3671
URL: https://issues.apache.org/jira/browse/WICKET-3671
Project: Wicket
Issue Type: Bug
Components: wicket-core
Affects Versions: 1.4.16
Reporter: Antti S. Lankila
Priority: Minor
This issue probably affects all versions of wicket. I have encountered it on
1.4.16.
Let's assume a structure in page such as Page -> Form -> ListView -> TextField.
Localizer#getCacheKey() generates cache keys for the TextField using string
resource lookups which omit the component that is direct child of
AbstractRepeater (= ListItem). This results in construction of cache keys in
form formName.repeaterName.fieldName, that is, without the ListItem ID. These
cache keys are used to quickly return the string resource that was returned
last time for component in similar relationship in page.
Howver, this is inconsistent with actual string resource lookup for elements
that are children of ListItem. Namely, the string resource lookup contains the
row ID, resulting a string resource lookup for this key in properties file:
formName.repeaterName.0.fieldName. It appears to use the full page relative
path to the component, in other words.
This combined with the cacheKey calculation such that wicket generally works
correctly if one writes resource such as the following:
formName.repeaterName.0.fieldName = foo
because after the first row has been rendered, the Localizer has cached the
object's key, so for the next row it will look up the same result as for the
first row.
However, if the lookup doesn't occur on the first row (for instance because the
field is invisible on that row only) the the lookup is attempted first time on
the second row, requiring formName.repeaterName.1.fieldName to be found in the
properties file. The workaround can be to remove the path and only define
"fieldName = foo" in the properties file.
The correct solution might be to duplicate the cacheKey calculation in the
string resource lookup for a field.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
