Uploaded image for project: 'ZK'
  1. ZK
  2. ZK-3312

Unexpected @load binding triggers


    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • 8.0.4
    • 8.0.2
    • Databind 2
    • Security Level: Jimmy
    • None
    • ZK 8.0.4 S1

      steps to reproduce

      run the attached example equal-list-load-binding.zul

      and click the buttons:
      1. remove an item
      2. notify unrelated list

      actual result

      1. the first element from the ListModel is removed OK
      2. the listbox reloads its model and reverts the model change (not expected)

      expected result

      1. the first element from the ListModel is removed
      2. the listbox should not reload its model and remain unchanged

      debug info

      the second button calls notify change on the copiedList instance
      still the @load binding referring to the original list reloads

      root cause

      Since Lists are considered equal if their contents are equal and in the same order I suspect the BindTracker identifies a wrong @load binding and reloads it.

      originalList == copiedList => false (not the same instance)
      originalList.equals(copiedList) => true (still equal)

      I assume the Bind Tracking mechanism is keeping a lookup table (e.g. a HashMap based on equals) associating load bindings with both lists if they are equal, even if they are not the same. When notifying one of them the other one is loaded at the same time.

            DevChu DevChu
            cor3000 cor3000
            1 Vote for this issue
            3 Start watching this issue


                Original Estimate - Not Specified
                Not Specified
                Remaining Estimate - 0 minutes
                Time Spent - 1 day, 5 hours
                1d 5h