ListItem partakes in stringresource key generation, resulting in formName.repeaterName.0.fieldName like keys.

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.