Clone Tools
  • last updated a few minutes ago
Constraints: committers
Constraints: files
Constraints: dates
FLEX-34880 Added an asdoc recommendation that developers use Sort and SortField as immutable objects, although the current API allows for mutability.

  1. … 2 more files in changeset.
Revert FLEX-34880 part 3

This reverts commit 2b09e327281211d26d65dd5d061b02d645cbdd39.

  1. … 8 more files in changeset.
Revert FLEX-34880 part 1 This reverts commit 0b5a634dabb00c04a492a08375e29c6885c1486f.

  1. … 9 more files in changeset.
FLEX-34880 Placed the other ISortField setters behind mx_internal and removed them from the interface.

  1. … 9 more files in changeset.
FLEX-34880 Placed only one state setter (SortField.compareFunction) behind mx_internal (thus also renaming it to SortField.compareFunction_) to provide the template for the others. Also removed it from the interface (ISortField).

  1. … 8 more files in changeset.
FLEX-35043 PROBLEM: The assumptions in SF_ORIG_list_events_tester.List_events_collectionKind_move made obvious another problem caused by FLEX-34885: calling itemUpdated(item) did not reposition the item according to the sorting rules (unless the Sort had a customCompareFunction).

CAUSE: FLEX-34885 assumed that the initial logic of checking for ! was to detect when entire objects were replaced with others in the collection. However, it was also detecting when the developer signalled that something (undefined) about an object had changed, and they wanted the sorting / filtering to be reapplied.

SOLUTION: now we call moveItemInView() also when is null and there are no oldValue or newValue specified in the CollectionEvent.


-also updated ListCollectionView_PropertyChangeEvent_Tests and added a new function for objects which are not bindable. As expected, there is a failure without this change to ListCollectionView, and with the change all unit tests pass.

-made explicit a conversion from Object into Boolean in a call to moveItemInView().

-reformated event instantiations to be on one line.

-made some minor changes to SF_ORIG_ListBasic.mxml, which is used by SF_ORIG_list_events_tester.

  1. … 2 more files in changeset.
FLEX-34852 Mentioning that the spark version of ComplexSortField is preferable.

Revert "TFC-12136"

This reverts commit 45e61644e6a3543937a0fa3db11c3b98b228ae2d.

TFC-12136 Removing all the PropertyChangeEvent dispatches which have no value set for property and oldValue, and the itemUpdated() calls in collections (which yield the same type of events) when they come after updates to object's public and bindable properties, because that makes the dispatches superfluous. (The ones I'm leaving in are the ones after updating private properties on objects, so after bypassing the bindable getters and setters, e.g. in AbstractEmployeeTimeAllocationGroupTO; and the ones I don't have time to understand why they're there.)

As a result, IMulticurrencyLineItem does not need to extend IEventDispatcher anymore.


-see the comment in this ticket for why it should be pretty safe to do this.

-also made some minor refactoring where appropriate.

FLEX-35043 CAUSE: The solution implemented for FLEX-34885, which had an problematic consequence: 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 had been just introduced to the collection - as "property" was null -, replacing a null value - since oldValue was null as well. (That is to say, when the "property" value of the PropertyChangeEvent was null, it was taken to mean that the oldValue - which was also null here - 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).

In a way this was logical based on the properties supplied to itemUpdated(), but we also know that a frequent use of that function is with only one parameter, to specify that some of the object's properties have changed (but the object itself should still be in the collection). So we should continue to support this use case.

SOLUTION: now ListCollectionView.handlePropertyChangeEvents() only assumes that the entire object has been replaced in the collection if the event's "property" is null AND if either its "oldValue" or "newValue" is non-null. In other words, if the developer entered all these arguments into the function or in the event they're dispatching, and one of them is non-null, it probably means they want to signal that the entire object has changed in the collection.


-renamed "entireObjectChanged" into "objectReplacedWithAnother" to emphasize that it's not the object's internal state that "entirely changed", but that the object itself was replaced in the collection by another object instance.

-some of the unit tests in ListCollectionView_PropertyChangeEvent_Tests are now failing, which is expected.

FLEX-34885 Added a new unit test class, ListCollectionView_PropertyChangeEvent_Tests, that not only tests a few scenarios to make sure that ListCollectionView reacts as expected to PropertyChangeEvents, but also makes explicit 2 of the consequences of manually dispatching PropertyChangeEvents through the VOs in the list without specifying a "property" and an "oldValue" in the PropertyChangeEvent: 1. null is assumed to have been replaced in the collection by that VO, so it will be removed if it already exists. This may be unexpected to developers. 2. if there's a customCompareFunction in the Sort object, it will be called with null as one of the arguments. This may again be unexpected to developers.


-also removed some whitespace and improved asdocs.

  1. … 1 more file in changeset.
FLEX-35031 FLEX-33058 -Simplified algorithm in findAny() and findLast(). -Improved asdoc for these functions. Note that all tests still pass.

  1. … 1 more file in changeset.
FLEX-35031 Added two more test functions to make explicit the assumption that searching by sealed class instances with a subset of the properties of the object to be found will NOT work (analogous to searching by anonymous objects with a subset of the properties of the target object, which should work, as documented in the same class), at least at the moment. There is no business case for it, and the framework itself doesn't seem to require it. -A couple of other minor changes, like removing unused imports and editing asdocs.

  1. … 2 more files in changeset.
FLEX-33058 Minor refactoring while reading codeȘ -simplified if statements -corrected asdocs -optimized imports -removed unused variables

  1. … 3 more files in changeset.
FLEX-20313 Applied the asdoc changes suggested by the comment made on 28/Jan/12 00:20.

FLEX-34837 Asdoc corrections, plus making one function static.

  1. … 2 more files in changeset.
FLEX-34837 CAUSE: DataGrid never had a mechanism by which it could monitor changes to the complex dataFields (e.g. "address.street") of the items in its dataProvider. Because of this, it couldn't ask for the collection to re-sort its items when one of these values changed. The best it could do was to keep track of when these values changed through its GridItemEditor, which it could detect.

SOLUTION: Now ListCollectionView can be asked (by DataGrid.ensureComplexFieldsMonitoring) to monitor all changes to the complex fields by which it's sorted (through the ComplexFieldChangeWatcher). Whenever one of them changes, the collection is resorted. Also, the sorting that GridColumn used to do through one of its own sortFunctions, is now left to Sort and SortField to do, as they've specialized in complex fields as well.


-This also means that GridItemEditor doesn't need to manually dispatch an itemUpdated event each time an item has been edited through it.

  1. … 7 more files in changeset.
FLEX-34852 Fixing mustella failure introduced by a commit on this ticket. The bug was that SortField.objectHasSortFieldValue() returned true instead of false when the object didn't have that field. This was because an object typed as Object is always null, even when undefined is assigned to it. It needed to be typed as *. (This is reproduced in

  1. … 1 more file in changeset.
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 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 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.


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.


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


-Now all the functions in FLEX_34854_Tests pass.

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