[
https://issues.apache.org/jira/browse/FLEX-33629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Chira updated FLEX-33629:
-------------------------------
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.
was:
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.
> 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?
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: FLEX-33629
> URL: https://issues.apache.org/jira/browse/FLEX-33629
> Project: Apache Flex
> Issue Type: Question
> Components: Spark: DropDownList
> Affects Versions: Apache Flex 4.9.0
> Reporter: Mihai Chira
> Priority: Critical
> Attachments: _DropDownDoubleBound.fxp
>
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
