[
https://issues.apache.org/jira/browse/WICKET-3671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl reassigned WICKET-3671:
----------------------------------
Assignee: Peter Ertl
> 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, 1.5-RC3
> Reporter: Antti S. Lankila
> Assignee: Peter Ertl
> 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 -> ListItem
> -> 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 path lookup.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
