flex-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mihai Chira (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (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?
Date Tue, 23 Jul 2013 11:02:48 GMT

     [ 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

Mime
View raw message