Apache Flex
  1. Apache Flex
  2. FLEX-33629

Is this the expected (and planned for the future) behaviour for a dropdownlist with its selectedItem two-way bound and set before the data provider?

    Details

    • Type: Question Question
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: Apache Flex 4.9.0
    • Fix Version/s: None
    • Component/s: Spark: DropDownList
    • Labels:
      None

      Description

      Run the attached application, and press one of the two buttons on the left.

      Actual behaviour: the selectedItem should represent the owner of that job, but it's now wrong because the selectedItem has been assigned before the dataProvider, so the first item in the list has been selected (and set in the model) instead, because requireSelection was "true" in the dropdownlist.

      Desired behaviour: not sure, but modifying the model with invalid data because of the timing of assignments in a visual component (without any user input) feels unintended and definitely surprising. We have lots of forms in our application, and the team spent an aggregate of around two weeks chasing various bugs that all came down to the timing between assigning selectedItem and dataProvider in dropdowns.

      A few suggestions:
      -to keep the problem discoverable, but not mess up the model, there could be an additional property on the dropdownlist called userSelectedItem, to which the developers could safely bind two-ways, as the trigger would only fire for the "change" event - thus, when the user selects an item from the list. Please see ExtendedDropDownList in the project for an example. When we bind to userSelectedItem, the selection in the dropdown is still wrong, but the model is intact (replace DropDownList with ExtendedDropDownList in _DropDownDoubleBound.mxml and two-way bind to userSelectedItem instead of selectedItem).
      -the binding trigger event could be "change" instead of "valueCommit" ("dispatchEvent(new FlexEvent(FlexEvent.VALUE_COMMIT));" in ListBase.commitSelection() seems to trigger the bindings now.)
      -the DropDownList could throw an error when the selectedItem cannot be found in the dataProvider.

      All the potential solutions above have benefits and drawbacks, but I guess it might be a good idea to start a discussion on what the best direction could be for this issue.

        Issue Links

          Activity

          Mihai Chira created issue -
          Mihai Chira made changes -
          Field Original Value New Value
          Attachment _DropDownDoubleBound.fxp [ 12593684 ]
          Mihai Chira made changes -
          Description Run the attached application, and press one of the two buttons on the left.

          Actual behaviour: the selectedItem should represent the owner of that job, but it's now wrong because the selectedItem has been assigned before the dataProvider, so the first item in the list has been selected (and set in the model) instead, because requireSelection was "true" in the dropdownlist.

          Desired behaviour: not sure, but modifying the model with invalid data because of the timing of assignments in a visual component (so without any user input) feels unintended and definitely surprising. We have lots of forms in our application, and the team spent an aggregate of around two weeks chasing various bugs that all came down to the timing between assigning selectedItem and dataProvider in dropdowns.

          A few suggestions:
          -to keep the problem discoverable, but not mess up the model, there could be an additional property on the dropdownlist called userSelectedItem, to which the developers could safely bind two-ways, as the trigger would only fire for the "change" event - thus, when the user selects an item from the list. Please see ExtendedDropDownList in the project for an example. When we bind to userSelectedItem, the selection in the dropdown is still wrong, but the model is intact (replace DropDownList with ExtendedDropDownList in _DropDownDoubleBound.mxml and two-way bind to userSelectedItem instead of selectedItem).
          -the binding trigger event could be "change" instead of "valueCommit" ("dispatchEvent(new FlexEvent(FlexEvent.VALUE_COMMIT));" in ListBase.commitSelection() seems to trigger the bindings now.)
          -the DropDownList could throw an error when the selectedItem cannot be found in the dataProvider.


          All the potential solutions above have benefits and drawbacks, but I guess it might be a good idea to start a discussion on what the best direction could be for this issue.
          Run the attached application, and press one of the two buttons on the left.

          Actual behaviour: the selectedItem should represent the owner of that job, but it's now wrong because the selectedItem has been assigned before the dataProvider, so the first item in the list has been selected (and set in the model) instead, because requireSelection was "true" in the dropdownlist.

          Desired behaviour: not sure, but modifying the model with invalid data because of the timing of assignments in a visual component (without any user input) feels unintended and definitely surprising. We have lots of forms in our application, and the team spent an aggregate of around two weeks chasing various bugs that all came down to the timing between assigning selectedItem and dataProvider in dropdowns.

          A few suggestions:
          -to keep the problem discoverable, but not mess up the model, there could be an additional property on the dropdownlist called userSelectedItem, to which the developers could safely bind two-ways, as the trigger would only fire for the "change" event - thus, when the user selects an item from the list. Please see ExtendedDropDownList in the project for an example. When we bind to userSelectedItem, the selection in the dropdown is still wrong, but the model is intact (replace DropDownList with ExtendedDropDownList in _DropDownDoubleBound.mxml and two-way bind to userSelectedItem instead of selectedItem).
          -the binding trigger event could be "change" instead of "valueCommit" ("dispatchEvent(new FlexEvent(FlexEvent.VALUE_COMMIT));" in ListBase.commitSelection() seems to trigger the bindings now.)
          -the DropDownList could throw an error when the selectedItem cannot be found in the dataProvider.


          All the potential solutions above have benefits and drawbacks, but I guess it might be a good idea to start a discussion on what the best direction could be for this issue.
          Mihai Chira made changes -
          Link This issue relates to FLEX-20957 [ FLEX-20957 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              Mihai Chira
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Development