On 6/1/14 6:01 PM, "Michael A. Labriola" <labri...@digitalprimates.net>
wrote:
>>>>You should get an arg count mismatch. By changing the
>>>>(!hasFieldName) test on Sort.as line 413 I got the expected result
>>>>("Find criteria must contain all sort fields")
>>>
>
>Okay, so this is where I have an issue that I am not sure how we should
>resolve. I don't agree with the expected result.
>
>If I provide a custom sort function for a SortField, then why should Sort
>use the 'name' of the ISortField to determine whether or not this
>particular SortField is valid? If something has a SortField with a custom
>sort function, why should we believe that we know more about what the
>user intended and assume that there sort even uses the 'name' property
>for the SortField. The custom sort could be using multiple fields or, for
>all we care, derived from a completely different source. Why would we
>decide if its valid or not based on whether the 'name' can be simply
>indexed into the data provider's object?
It's a valid question. There is probably no one right answer. My answer
is that, if you didn't intend the compareFunction to use the field name in
the SortField, why use a SortField at all? Why not just use the top-level
Sort compareFunction.
Anyway, as I suggested to Nick and his XMLListCollection change, the
answer might just be to add a flag or two so folks can have old behavior
or new behavior.
-Alex
