Folks keep trying to find ways to avoid calls to refresh() and we keep
ending up with other side-effects.  Seems dangerous (from a backward
compatibility standpoint) to be making changes like this.

You could experiment with a new set of Sort classes that take a reference
to an LCV and auto-call refresh() on it as things change.  That might get
you what you want and not break anybody.

-Alex

On 5/22/15, 7:33 AM, "Tom Chiverton" <t...@extravision.com> wrote:

>I thought it was meant to work this way, you can do what you like to
>collection.sort but nothing happens until the call refresh(). This is
>helpful if you have to make several changes to the sort (rather than
>just a one line change to sort.fields) as it avoids multiple re-sorts on
>a partially set up sort.
>
>Tom
>
>On 22/05/15 15:28, Mihai Chira wrote:
>> I started to work on this and realised that this might be seen as a
>> pseudo-feature, rather than a bug. (To my mind it's a bug.) Pseudocode
>> for how it works now and how I think it should work:
>> 1. NOW:
>>
>> const sortByIndexAscending:Sort = new Sort();
>> sortByIndexAscending.fields = [new SortField("index", false, false,
>>true)];
>> collection.sort = sortByIndexAscending;
>> collection.refresh(); //sorts
>> collection.sort.fields = [new SortField("name", false, true, false)];
>> //nothing happens
>> collection.getItemIndex(firstItemInCollection); //THROWS A RUNTIME
>> ERROR - see Jira ticket
>>
>> 2. SHOULD (but open to discussion, of course)
>> const sortByIndexAscending:Sort = new Sort();
>> sortByIndexAscending.fields = [new SortField("index", false, false,
>>true)];
>> collection.sort = sortByIndexAscending;
>> collection.refresh(); //sorts
>> collection.sort.fields = [new SortField("name", false, true, false)];
>> //SORT HAPPENS AGAIN
>> collection.getItemIndex(firstItemInCollection); //works a treat
>>
>> The only reason I can see why things should stay as they are is
>> because some people might have Sort objects that they're reusing
>> between collections, and might not realise that (after this change
>> happens) all their collections will resort once the fields change. To
>> me, though, it's not reason enough to keep this potential for runtime
>> errors.
>>
>> Thoughts?
>>
>> On 22 May 2015 at 16:19, Mihai Chira (JIRA) <j...@apache.org> wrote:
>>>       [ 
>>>https://issues.apache.org/jira/browse/FLEX-34853?page=com.atlassian.jira
>>>.plugin.system.issuetabpanels:all-tabpanel ]
>>>
>>> Mihai Chira updated FLEX-34853:
>>> -------------------------------
>>>      Issue Type: Bug  (was: New Feature)
>>>
>>>> ListCollectionView.getItemIndex throws RTE when the Sort's sortFields
>>>>change
>>>> 
>>>>-----------------------------------------------------------------------
>>>>-----
>>>>
>>>>                  Key: FLEX-34853
>>>>                  URL: https://issues.apache.org/jira/browse/FLEX-34853
>>>>              Project: Apache Flex
>>>>           Issue Type: Bug
>>>>           Components: Collections, Spark: Sort and SortField
>>>>     Affects Versions: Apache Flex 4.14.1
>>>>             Reporter: Mihai Chira
>>>>             Assignee: Mihai Chira
>>>>              Fix For: Apache Flex 4.15.0
>>>>
>>>>
>>>> {code}
>>>>              _sut.addAll(from4To0); //values["name"]: Object4,
>>>>Object3, Object2, Object1, Object0
>>>>              const sortByIndexAscending:Sort = new Sort();
>>>>              sortByIndexAscending.fields = [new SortField("index",
>>>>false, false, true)];
>>>>              _sut.sort = sortByIndexAscending;
>>>>              _sut.refresh(); //should be: Object0, Object1, Object2,
>>>>Object3, Object4
>>>>              //when
>>>>              sortByIndexAscending.fields = [new SortField("name",
>>>>false, true, false)]; //should have no effect
>>>>              //then
>>>>              assertThat(_sut.getItemIndex(from4To0.getItemAt(i)) !=
>>>>-1); //an RTE is thrown here
>>>> {code}
>>>> *Expected behaviour*: the collection should redo the sort when any of
>>>>its sort's flags changes, or whenever one of the sortFields' flags
>>>>changes.
>>>
>>>
>>> --
>>> This message was sent by Atlassian JIRA
>>> (v6.3.4#6332)
>> ______________________________________________________________________
>> This email has been scanned by the Symantec Email Security.cloud
>>service.
>> For more information please visit http://www.symanteccloud.com
>> ______________________________________________________________________
>>
>

Reply via email to