Wicket
  1. Wicket
  2. WICKET-3671

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

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.4.16, 1.5-RC3
    • Fix Version/s: 1.4.18, 1.5-RC4
    • Component/s: wicket
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        Antti S. Lankila added a comment -

        Confirmed fixed in 1.5-RC4. Thank you.

        Show
        Antti S. Lankila added a comment - Confirmed fixed in 1.5-RC4. Thank you.
        Hide
        Antti S. Lankila added a comment -

        Will test when during migrating to wicket 1.5rc4, when it is released.

        Show
        Antti S. Lankila added a comment - Will test when during migrating to wicket 1.5rc4, when it is released.
        Hide
        Peter Ertl added a comment -

        Should be working now, please test and confirm.

        Show
        Peter Ertl added a comment - Should be working now, please test and confirm.

          People

          • Assignee:
            Peter Ertl
            Reporter:
            Antti S. Lankila
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development