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

        Antti S. Lankila created issue -
        Antti S. Lankila made changes -
        Field Original Value New Value
        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 -> 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 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.
        Peter Ertl made changes -
        Assignee Peter Ertl [ pete ]
        Peter Ertl made changes -
        Affects Version/s 1.5-RC3 [ 12316220 ]
        Priority Minor [ 4 ] Major [ 3 ]
        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.
        Peter Ertl made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 1.4.18 [ 12316329 ]
        Fix Version/s 1.5-RC4 [ 12316330 ]
        Resolution Fixed [ 1 ]
        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
        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.
        Antti S. Lankila made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        13h 36m 1 Peter Ertl 06/May/11 08:05
        Resolved Resolved Closed Closed
        5d 7h 20m 1 Antti S. Lankila 11/May/11 15:25

          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