Pivot
  1. Pivot
  2. PIVOT-569

Make ListView selectedItem, etc. notifying properties

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0
    • Component/s: wtk
    • Labels:
      None

      Description

      These properties don't currently fire events when they change, so it is not possible to dynamically bind to them using namespace bindings.

      Note that they should only fire when selectMode == SINGLE.

        Activity

        Hide
        Greg Brown added a comment -

        Prototyping this feature revealed some design issues that need to be considered, so I am moving this to 2.1.

        Show
        Greg Brown added a comment - Prototyping this feature revealed some design issues that need to be considered, so I am moving this to 2.1.
        Hide
        Greg Brown added a comment -

        As discussed, this might be best implemented using an annotation that creates a dependency association between properties (e.g. "fire 'selectedItem' change events whenever 'selectedIndex' changes).

        Show
        Greg Brown added a comment - As discussed, this might be best implemented using an annotation that creates a dependency association between properties (e.g. "fire 'selectedItem' change events whenever 'selectedIndex' changes).
        Hide
        Michael Allman added a comment -

        I did this for a subclass of ListButton. I just added an event listener for selectedIndexChanged in the constructor that dispatches a selectedItemChanged event from there. Upon review, I should probably be checking for inequality of the selected items before firing the event in case equal objects exist at different indices of the list.

        If you set up ListView to dispatch selectedItemChanged can you do that for ListButton, too?

        Show
        Michael Allman added a comment - I did this for a subclass of ListButton. I just added an event listener for selectedIndexChanged in the constructor that dispatches a selectedItemChanged event from there. Upon review, I should probably be checking for inequality of the selected items before firing the event in case equal objects exist at different indices of the list. If you set up ListView to dispatch selectedItemChanged can you do that for ListButton, too?
        Hide
        Greg Brown added a comment -

        Yes, we'll be doing this for all data-driven components (ListButton, ListView, Spinner, TableView, and TreeView).

        Show
        Greg Brown added a comment - Yes, we'll be doing this for all data-driven components (ListButton, ListView, Spinner, TableView, and TreeView).
        Hide
        Greg Brown added a comment -

        Now that I think about this more, I am wondering if an annotation might not be the right approach. The annotation implies that whenever the selected index change event is fired, the selected item change event will also be fired. However, there are cases when that may not be correct. Selected index and selected item changes are only 1:1 when the selected index is changed explicitly, or the selected item itself is deleted and the selected index is reset to -1. Otherwise, the actual selected item does not change, so an event would be incorrect.

        Another down side to the annotation is that there is no actual selectedItemChanged() method a caller can implement. Callers could only be notified of this event via a bean monitor property change event. That may not be convenient, and it is not consistent with the rest of the framework.

        Show
        Greg Brown added a comment - Now that I think about this more, I am wondering if an annotation might not be the right approach. The annotation implies that whenever the selected index change event is fired, the selected item change event will also be fired. However, there are cases when that may not be correct. Selected index and selected item changes are only 1:1 when the selected index is changed explicitly, or the selected item itself is deleted and the selected index is reset to -1. Otherwise, the actual selected item does not change, so an event would be incorrect. Another down side to the annotation is that there is no actual selectedItemChanged() method a caller can implement. Callers could only be notified of this event via a bean monitor property change event. That may not be convenient, and it is not consistent with the rest of the framework.
        Hide
        Greg Brown added a comment -

        After some additional thought, I think that explicit listener methods for these events is the right approach. It is more consistent with existing events, and, more importantly, these events are not redundant - they simply represent a different use case.

        For example: ListView selection listeners must currently listen for selectedRangesChanged() even when the list is in single-select mode. A selectedItemChanged() event would probably make a lot more sense to those callers, since multiple ranges will never be selected.

        Another (existing) example is TextInputTextListener - this interface contains an ostensibly redundant textChanged() method that is called any time the text input's text changes. Callers could listen for charactersInserted() and charactersRemoved() directly, but this wouldn't be as convenient. The selectedRangesChanged() event in ListViewSelectionListener and TableViewSelectionListener behaves similarly.

        Given that there are existing similar examples, and that tying selectedItemChanged() directly to selectedIndexChanged() would result in spurious events (when the selected index changes indirectly due to a model change), I think I would recommend not using an annotation here.

        Show
        Greg Brown added a comment - After some additional thought, I think that explicit listener methods for these events is the right approach. It is more consistent with existing events, and, more importantly, these events are not redundant - they simply represent a different use case. For example: ListView selection listeners must currently listen for selectedRangesChanged() even when the list is in single-select mode. A selectedItemChanged() event would probably make a lot more sense to those callers, since multiple ranges will never be selected. Another (existing) example is TextInputTextListener - this interface contains an ostensibly redundant textChanged() method that is called any time the text input's text changes. Callers could listen for charactersInserted() and charactersRemoved() directly, but this wouldn't be as convenient. The selectedRangesChanged() event in ListViewSelectionListener and TableViewSelectionListener behaves similarly. Given that there are existing similar examples, and that tying selectedItemChanged() directly to selectedIndexChanged() would result in spurious events (when the selected index changes indirectly due to a model change), I think I would recommend not using an annotation here.
        Hide
        Greg Brown added a comment -

        Resolved for ListButton, Spinner, and SuggestionPopup.

        Show
        Greg Brown added a comment - Resolved for ListButton, Spinner, and SuggestionPopup.
        Hide
        Greg Brown added a comment -

        Resolved for ListView and TableView.

        Show
        Greg Brown added a comment - Resolved for ListView and TableView.
        Hide
        Greg Brown added a comment -

        Assigning to Todd for TreeView.

        Show
        Greg Brown added a comment - Assigning to Todd for TreeView.
        Hide
        Greg Brown added a comment -

        Resolved for TreeView.

        Show
        Greg Brown added a comment - Resolved for TreeView.

          People

          • Assignee:
            Todd Volkert
            Reporter:
            Greg Brown
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development