Clone Tools
  • last updated 26 mins ago
Constraints: committers
Constraints: files
Constraints: dates
FLEX-34854 Refactored ComplexFieldChangeWatcher to allow for monitoring of additions to the sorted list.


-Now all the functions in FLEX_34854_Tests pass.

-Now we're using 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
  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.


-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
  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.


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).


-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.


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. ""). 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
  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.

XMLListCollection updates to make addItem() more efficient.

Update to XMLListCollection. Added docs to XMLListAdapter to better represent what is happening.

Now XMLListCollection behaves closer to be expected -- does not update parent from updated XMLList. I guess it should be debated wether it should...

Fix for issue FLEX-34320

FLEX-34101 likley fix for regression issue

FLEX-34108 Change to simpler implementation. On 10.2/10.3 no issue as the function shouldn't be called directly.

reverting FLEX-34101 as this cause several spark list test to fails and one to RTE

FLEX-34108 changed code so it compile under 10.2/10.3 and still works under 11.0+

Now able to compile on 10.2 and 10.3 which doesn't have JSON support

FLEX-34101 spark list doesn't refresh with filterFunction + fix RTE that occurs when adding more than one item to a filtered list.

FLEX-34108 add toJSON to ArrayCollection and ArrayList