Clone Tools
  • last updated 29 mins ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
FLEX-34854 Minor edits while checking a mustella failure.

  1. … 1 more file in changeset.
FLEX-34854 spark.collections.Sort.sort() was very similar to mx.collections.Sort.sort(), with the only difference in the fact that the latter tried to use Array.sortOn when appropriate. So, to remove the duplication I introduced a new flag to the mx version called useSortOn, which the spark version defaults to false. This way I could completely remove spark.collections.Sort.sort() and reset a few members of the mx version as private, as before.

  1. … 1 more file in changeset.
FLEX-34854 The spark Sort now extends the mx version, to prevent the need of changing both classes when a bug is fixed or a feature is implemented. NOTES: -this is a result of the mailing list discussion entitled 'Can we unify spark and mx Sort and SortField?'. -some members of mx.collections.Sort needed to be marked protected so that the sort() function could access them. In the next commit they will be reverted by implementing a way in which the sort() function doesn't need to be overridden. -mx.collections.Sort needed to have a new method, createEmptySortField(), which is now used by noFieldsCompare(), and that ensures that the differences in spark.collections.Sort.noFieldsCompare() are preserved without having to copy-paste the entire method.

  1. … 1 more file in changeset.
FLEX-34854 Changes to asdocs comments to get the spark and mx versions of Sort.as more similar.

  1. … 1 more file in changeset.
FLEX-34854 The spark SortField now extends the mx version, to prevent the need of changing both classes when a bug is fixed or a feature is implemented. NOTES: -this is a result of the mailing list discussion entitled 'Can we unify spark and mx Sort and SortField?'. -the compareFunction getter and setter have been kept only for the asdoc comment to show the differences between the spark and mx SortField. -the spark DataGrid was using AdvancedStyleClient to refer to spark SortFields instead of the interface, IAdvancedStyleClient. This needed to be corrected, because the spark SortField does not extend AdvancedStyleClient anymore. -SortField.stringCompare() and .xmlCompare() needed to be protected (they were private) so that they could be overridden in spark SortField.

  1. … 3 more files in changeset.
FLEX-34727 changed original patch to actuall check for reset and refresh event kinds. Previous patch would have broken adding/removing nulls

FLEX-34727 items array in CollectionEvent now has 0 items when refresh or reset

FLEX-34885 CAUSE: When an item is marked as updated, ListCollectionView.handlePropertyChangeEvents() assumes that it's just one property of the item that changed. However, an entire item could have changed (see the unit test committed on this ticket), in which case PropertyChangeEvent.property is null or empty. When this happens, the new item is added to the localIndex correctly, but the old one is not removed. Moreover, ArrayList still listens to the removed item for changes, and when one occurs, as in the unit test, the event it sends causes the item to be re-added to the localIndex via ListCollectionView.handlePropertyChangeEvents(). Moreover, ArrayList does not listen to the new object for changes, causing the sorting to be wrong in the wrapping ListCollectionView.

SOLUTION:

ListCollectionView.handlePropertyChangeEvents() now caters for the situation where a PropertyChangeEvent refers to an object that changed into another one (rather than just one of its properties). Also, ArrayList now removes the listeners to the old item and adds them to the new item.

FLEX-34854 Renamed a local variable to make it more clear what type of items is in the Array.

FLEX-34854 Collection RESET and REFRESH now get the ComplexFieldChangeWatcher to listen to the new events. (Unit tested.)

  1. … 2 more files in changeset.
FLEX-34854 Items removed from the collection are not watched for changes anymore.

NOTES:

-to be able to unwatch individual items the storage for the watchers had to change into a (weakly typed) Dictionary.

FLEX-34854 Refactored ComplexFieldChangeWatcher to allow for monitoring of additions to the sorted list.

NOTES

-Now all the functions in FLEX_34854_Tests pass.

-Now we're using ChangeWatcher.watch instead of BindingUtils.bindSetter, to avoid unnecessary steps and memory allocation.

FLEX-34854 Externalized the complex field watching functionality from ListCollectionView into ComplexFieldChangeWatcher. The same unit tests that passed before still pass now.

    • -0
    • +92
    ./ComplexFieldChangeWatcher.as
  1. … 1 more file in changeset.
FLEX-34854 First unit test and implementation of watching for changes in complex fields. Also, ComplexSortField now caters for the case when the field name is null.

NOTES

-Changes are monitored for the objects which existed in the collection before the sort was applied, not for the new ones. This is to follow.

-The watching functionality will be externalized from ListCollectionView in the following commits.

    • -0
    • +24
    ./IComplexSortField.as
  1. … 1 more file in changeset.
FLEX-34884 CAUSE The reason items weren't findable in a collection sorted by complex fields was that Sort.findItem() was going through the field names to make sure that all of them are present on the destination objects. This check failed for complex objects.

SOLUTION

Instead of checking by itself, Sort.findItem() now delegates this responsibility to the respective ISortFields. In turn, SortField and ComplexSortField can now tell Sort whether an object has a certain property and, respectively, whether an object has the first property in the chain for ComplexSortField (because any part of the chain can be null without meaning the entire chain can never be accessed - it just can't be accessed now).

NOTES

-Now the previously added unit test passes.

-Also note that in this way Sort.fieldList is no longer needed, which should speed up the fields setter.

FLEX-34853, FLEX-34879 CAUSE: ListCollectionView.getItemIndex() uses findItem() which, along with findFirst(), findAny() and findLast(), always use the Sort to do the searching if the collection is already sorted. However, this assumes that all the current properties of Sort (including the properties of its SortFields) accurately represent the current sorting order in the collection, which is not the case. The reason is that one can change any property of Sort and SortField without the collection noticing. This leads to the error.

SOLUTION:

After discussing it with Alex H, I decided to implement a step-by-step transformation of SortField and Sort into true (i.e. immutable) value objects. They are suited to this design pattern because they have no identity, and the fact that they are now mutable has allowed this bug to exist. This way, no property will be changeable on SortField and Sort without recreating an object (and potentially cloning an existing one).

This first step (FLEX-34879) is to mark the setters and the reverse() functions as deprecated for the next release, and to ensure that users can specify all the state fields directly in the constructors.

  1. … 2 more files in changeset.
FLEX-34852 Added more unit tests to check for edge cases, and for Sort.unique variations. Also replaced the last inline sort field value retrieval in SortField (in initializeDefaultCompareFunction()).

  1. … 1 more file in changeset.
FLEX-34852 Removing unused local variables.

FLEX-34852 ComplexSortField is now able to retrieve the value of a complex property using the newly introduced ObjectUtil.getValue. This is achieved by extracting SortField's sort field (currently inline) value retrievals into a protected function called getSortFieldValue() and overriding it in ComplexSortField. Also, ComplexSortField.arraySortOnOptions returns -1 to specify that Array.sortOn should not be used by Sort (because it cannot sort by field chains). Note that at this point FLEX_34852_Tests pass.

FLEX-34852 Introducing ComplexSortField to specify that a sort field name is actually a chain of properties separated by a dot (e.g. "address.name"). This was necessary because, as Alex H pointed out, one can add a property with a dot onto a dynamic object, and developers should still be able to sort by it using the existing algorithm.

    • -0
    • +37
    ./ComplexSortField.as
  1. … 1 more file in changeset.
FLEX-34854 Minor changes to imports, asdocs and removing an unused variable.

  1. … 2 more files in changeset.
FLEX-34837 Making the code intention more explicit and removing an IntelliJ code analysis warning.

FLEX-34838 Corrected some AsDocs, changed variable names from 'type' (reserved keyword) to other names, and removed unused variables.

  1. … 5 more files in changeset.
ArrayList performance optimization.

  1. … 1 more file in changeset.
FLEX-34285 fix issue with remove

Revert "Fix for issue FLEX-34320"

This reverts commit 798194db5eaf9aa28db4fd6027f78b40bb15800d.

Revert to previous version to stop mustella tests from failing. Work will continue in seperate branch.

Updated ASDocs for XMLListAdapter

Updated XMLListAdapter to optimize remove functions.

Update to make XMLListAdapter pass tests after last commit.