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-35043) Unexpected behaviour of ListCollectionView.itemUpdated() when only one parameter supplied
Date Thu, 31 Mar 2016 13:07:25 GMT

     [ https://issues.apache.org/jira/browse/FLEX-35043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mihai Chira updated FLEX-35043:
-------------------------------
    Description: 
See the unit tests in mx/collections/ListCollectionView_PropertyChangeEvent_Tests.as which
are tagged (in a comment, above the function) with FLEX-35043.

FLEX-34885 invalidated two previous assumptions:
# When calling itemUpdated(item) on a collection with only the first parameter provided (which
developers usually do to signal that some - unspecified - properties of the item have changed),
ListCollectionView.handlePropertyChangeEvents() would treat that as if the object has been
just introduced to the collection, replacing a null value - since oldValue was null, and property
was also null. (When the "property" value of the PropertyChangeEvent was null, it was taken
to mean that the oldValue - which was also null - was changed into that item, i.e. the object
reference changed in the collection, not just one of the object's properties.) As such, it
would try to remove that supposedly existing null value from the collection (and sometimes
a null does exist, but shouldn't be removed).
# The assumptions in SF_ORIG_list_events_tester.List_events_collectionKind_move (which started
failing) show that calling itemUpdated(item) does not reposition the item according to the
sorting rules anymore (unless the Sort has a customCompareFunction).

  was:
See the unit tests in mx/collections/ListCollectionView_PropertyChangeEvent_Tests.as which
are tagged (in a comment, above the function) with FLEX-35043.

When calling itemUpdated(item) on a collection with only the first parameter provided (which
developers usually do to signal that some - unspecified - properties of the item have changed),
ListCollectionView.handlePropertyChangeEvents() would treat that as if the object has been
just introduced to the collection, replacing a null value - since oldValue was null, and property
was also null. (When the "property" value of the PropertyChangeEvent was null, it was taken
to mean that the oldValue - which was also null - was changed into that item, i.e. the object
reference changed in the collection, not just one of the object's properties.) As such, it
would try to remove that supposedly existing null value from the collection (and sometimes
a null does exist, but shouldn't be removed).


> Unexpected behaviour of ListCollectionView.itemUpdated() when only one parameter supplied
> -----------------------------------------------------------------------------------------
>
>                 Key: FLEX-35043
>                 URL: https://issues.apache.org/jira/browse/FLEX-35043
>             Project: Apache Flex
>          Issue Type: Bug
>          Components: Collections
>    Affects Versions: Apache Flex 4.15.0
>            Reporter: Mihai Chira
>            Assignee: Mihai Chira
>             Fix For: Apache Flex 4.16.0
>
>
> See the unit tests in mx/collections/ListCollectionView_PropertyChangeEvent_Tests.as
which are tagged (in a comment, above the function) with FLEX-35043.
> FLEX-34885 invalidated two previous assumptions:
> # When calling itemUpdated(item) on a collection with only the first parameter provided
(which developers usually do to signal that some - unspecified - properties of the item have
changed), ListCollectionView.handlePropertyChangeEvents() would treat that as if the object
has been just introduced to the collection, replacing a null value - since oldValue was null,
and property was also null. (When the "property" value of the PropertyChangeEvent was null,
it was taken to mean that the oldValue - which was also null - was changed into that item,
i.e. the object reference changed in the collection, not just one of the object's properties.)
As such, it would try to remove that supposedly existing null value from the collection (and
sometimes a null does exist, but shouldn't be removed).
> # The assumptions in SF_ORIG_list_events_tester.List_events_collectionKind_move (which
started failing) show that calling itemUpdated(item) does not reposition the item according
to the sorting rules anymore (unless the Sort has a customCompareFunction).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message