Can we unify spark and mx Sort and SortField?

[Mihai Chira <mi...@gmail.com>]

I'm making lots of changes to SortField and Sort, and I'm realising
that having two versions of these files is error prone and duplicates
effort. From what I can see, the differences are:

Between mx.collections.SortField and spark.collections.SortField:
1. lots of asdocs changes
2. spark version ignores the caseInsensitive option
3. spark version extends AdvancedStyleClient, and has some more
functions for dealing with styles (like a "locale" style)
4. spark version uses a SortingCollator to compare strings, while mx
version uses ObjectUtil.stringCompare(), which uses
String.localeCompare(). Not sure how different these are.
Apart from a couple of bug fixes applied to both (except the bugs I'm
working on right now, which I currently only applied to the mx
version), they both arrived from the Adobe donation with these
differences.

Between mx.collections.Sort and spark.collections.Sort:
1. again, lots of asdocs changes
2. again, spark version extends AdvancedStyleClient, and has some more
functions for dealing with styles (like a "locale" style)
3. mx version uses Array.sortOn when it can, while spark version
doesn't (in the sort() function)
And the same as above, apart from a couple commits, they both came
from the Adobe donation with these differences.

Questions:
1. Can the spark versions be used with the mx components which
currently use the mx versions of Sort and SortField? I.e.
AdvancedDataGrid, DataGrid and DefaultCubeImpl. Or would there be
problems about these new style functions, or other issues?
2. If we can get the above to work, can we get rid of the mx versions?
I think it's really important to remove duplication, because all
changes to one version (e.g. the ones that I'm now making to sorting)
might have unintended consequences when ported to the other version
(or, even worse, we'll simply forget to do it, and still keep the bug
in the other version), and maintaining two almost identical sets of
unit tests is just impractical - not only would we have to make
changes and fixes in two places, but we'd also have to update two sets
of unit tests each time.

Thoughts?

Re: Can we unify spark and mx Sort and SortField?

[Justin Mclean <ju...@classsoftware.com>]

HI,

Off the top of my head (and it’s been a while since I’ve looked at the code so could be wrong) the spark class used the new i18n support in the FP so sorting in non en_US locales may give you different results in MX than spark. You may want to be be careful there as it may introduce subtle changes that are not immediately obvious.

Thanks,
Justin

Re: Can we unify spark and mx Sort and SortField?

[Mihai Chira <mi...@gmail.com>]

> Thanks for working on it.  What is it using instead of sortOn?
Array.sort(compareFunction)

> BTW, the build failed some sort tests.  See a recent set of results.
thanks for the heads up. Some are fixed, and some I'm now struggling
to debug (more details in the thread called "git commit: [flex-sdk]
[refs/heads/develop] - FLEX-34854 FLEX-34884 Adding unit test to make
sure that the changes in FLEX-34854 haven't changed anything about
findItem.").

Re: Can we unify spark and mx Sort and SortField?

[Alex Harui <ah...@adobe.com>]

On 6/21/15, 2:18 PM, "Mihai Chira" <mi...@gmail.com> wrote:

>This is now done (pending some unit tests) - see recent commits.
>
>Could someone please test that they can correctly sort an mx DataGrid
>by clicking on its columns in an MX-only project? For some reason when
>I try in IntelliJ I get this error[1]. And if you could try the same
>for a Spark-only project it would be ace.
>
>Also, does anyone know why spark.collections.Sort didn't use
>Array.sortOn in the sort() function? If not, does anyone see a problem
>if I add it?

Thanks for working on it.  What is it using instead of sortOn?

BTW, the build failed some sort tests.  See a recent set of results.

-Alex

Re: Can we unify spark and mx Sort and SortField?

[Mihai Chira <mi...@gmail.com>]

This is now done (pending some unit tests) - see recent commits.

Could someone please test that they can correctly sort an mx DataGrid
by clicking on its columns in an MX-only project? For some reason when
I try in IntelliJ I get this error[1]. And if you could try the same
for a Spark-only project it would be ace.

Also, does anyone know why spark.collections.Sort didn't use
Array.sortOn in the sort() function? If not, does anyone see a problem
if I add it?

[1] http://imgur.com/yB6HEz5

On 10 June 2015 at 14:58, Mihai Chira <mi...@gmail.com> wrote:
> That's very useful Peter, many thanks!
> It looks like I can use the framework.swc for the common part of these
> classes. Will get round to it later this week, I hope.
>
> On 10 June 2015 at 14:26, Peter Ginneberge <p....@gmail.com> wrote:
>>
>>
>> I had a quick look yesterday and when I toggled "mx only" vs "spark only"
>> I saw the mx.swc swapped for the spark.swc. A sparkskins.swc is added for
>> "spark only" while there is no equivalent for "mx only".
>>
>> For AIR projects a sparkair.swc is also added, there is again no mx
>> equivalent.
>>
>> Both component sets have a framework.swc, which I guess contains common
>> functionality used in both sets.
>>
>> regards,
>> Peter
>>
>>
>>
>> On 10/06/2015 12:59, Mihai Chira wrote:
>>>
>>> Great points, thanks all.
>>>
>>> Does anyone know how I can check which swcs are included in mx-only
>>> projects and which in spark-only projects, so I can see where I can put
>>> the
>>> common functionality if that's the route I / we'll choose? Thanks.
>>>
>>> On 10 June 2015 at 12:40, Kessler CTR Mark J <ma...@usmc.mil>
>>> wrote:
>>>
>>>> Issues I see or agree with.
>>>>
>>>> -MX only or Spark only projects.
>>>> -Inheritance of these classes / child classes.
>>>> -Possible different behavior.
>>>>
>>>>
>>>>
>>>> -Mark
>>>>
>>>
>

Re: Can we unify spark and mx Sort and SortField?

[Mihai Chira <mi...@gmail.com>]

That's very useful Peter, many thanks!
It looks like I can use the framework.swc for the common part of these
classes. Will get round to it later this week, I hope.

On 10 June 2015 at 14:26, Peter Ginneberge <p....@gmail.com> wrote:

>
> I had a quick look yesterday and when I toggled "mx only" vs "spark only"
> I saw the mx.swc swapped for the spark.swc. A sparkskins.swc is added for
> "spark only" while there is no equivalent for "mx only".
>
> For AIR projects a sparkair.swc is also added, there is again no mx
> equivalent.
>
> Both component sets have a framework.swc, which I guess contains common
> functionality used in both sets.
>
> regards,
> Peter
>
>
>
> On 10/06/2015 12:59, Mihai Chira wrote:
>
>> Great points, thanks all.
>>
>> Does anyone know how I can check which swcs are included in mx-only
>> projects and which in spark-only projects, so I can see where I can put
>> the
>> common functionality if that's the route I / we'll choose? Thanks.
>>
>> On 10 June 2015 at 12:40, Kessler CTR Mark J <ma...@usmc.mil>
>> wrote:
>>
>>  Issues I see or agree with.
>>>
>>> -MX only or Spark only projects.
>>> -Inheritance of these classes / child classes.
>>> -Possible different behavior.
>>>
>>>
>>>
>>> -Mark
>>>
>>>
>>

Re: Can we unify spark and mx Sort and SortField?

[Peter Ginneberge <p....@gmail.com>]

I had a quick look yesterday and when I toggled "mx only" vs "spark only" I 
saw the mx.swc swapped for the spark.swc. A sparkskins.swc is added for "spark 
only" while there is no equivalent for "mx only".

For AIR projects a sparkair.swc is also added, there is again no mx equivalent.

Both component sets have a framework.swc, which I guess contains common 
functionality used in both sets.

regards,
Peter


On 10/06/2015 12:59, Mihai Chira wrote:
> Great points, thanks all.
>
> Does anyone know how I can check which swcs are included in mx-only
> projects and which in spark-only projects, so I can see where I can put the
> common functionality if that's the route I / we'll choose? Thanks.
>
> On 10 June 2015 at 12:40, Kessler CTR Mark J <ma...@usmc.mil>
> wrote:
>
>> Issues I see or agree with.
>>
>> -MX only or Spark only projects.
>> -Inheritance of these classes / child classes.
>> -Possible different behavior.
>>
>>
>>
>> -Mark
>>
>

Re: Can we unify spark and mx Sort and SortField?

[Mihai Chira <mi...@gmail.com>]

Great points, thanks all.

Does anyone know how I can check which swcs are included in mx-only
projects and which in spark-only projects, so I can see where I can put the
common functionality if that's the route I / we'll choose? Thanks.

On 10 June 2015 at 12:40, Kessler CTR Mark J <ma...@usmc.mil>
wrote:

> Issues I see or agree with.
>
> -MX only or Spark only projects.
> -Inheritance of these classes / child classes.
> -Possible different behavior.
>
>
>
> -Mark
>

RE: Can we unify spark and mx Sort and SortField?

[Kessler CTR Mark J <ma...@usmc.mil>]

Issues I see or agree with.

-MX only or Spark only projects.
-Inheritance of these classes / child classes.
-Possible different behavior.



-Mark

Re: Can we unify spark and mx Sort and SortField?

[Alex Harui <ah...@adobe.com>]

On 6/9/15, 3:29 PM, "Peter Ginneberge" <p....@gmail.com> wrote:

>
>I don't know which classes end up in which swc, but the same rule may
>apply 
>for Spark only projects in which case Spark classes extending mx ones may
>be a 
>no no as well.

Good point.  In this case the mx Sort and Sort field are already in the
framework.swc.  Justin’s point about differences in behavior are the most
important point.  But maybe it is possible to find a way to factor out the
common pieces and share them.

-Alex

Re: Can we unify spark and mx Sort and SortField?

[Peter Ginneberge <p....@gmail.com>]

I don't know which classes end up in which swc, but the same rule may apply 
for Spark only projects in which case Spark classes extending mx ones may be a 
no no as well.

regards,
Peter


> On 9 June 2015 at 15:35, Alex Harui <ah...@adobe.com> wrote:

>> Peter is correct that you want to be careful about having mx-only classes
>> depend on Spark classes.
>>
>>
>> You could try making mx classes the base class for the Spark classes, so
>> the Spark subclasses would add in the AdvancedStyleClient, but the guts of
>> the work is all done in the mx base classes.
>>
>> -Alex
>>

Re: Can we unify spark and mx Sort and SortField?

[Mihai Chira <mi...@gmail.com>]

Yep, good point, Peter.

I'll try that, Alex (making spark extend mx), I'll see how it goes.

On 9 June 2015 at 15:35, Alex Harui <ah...@adobe.com> wrote:
> Peter is correct that you want to be careful about having mx-only classes
> depend on Spark classes.
>
> And in the strictest sense, I suppose there is a chance that someone’s app
> depends on a difference in behavior between ObjectUtil and
> String.localeCompare, although I personally don’t think there is much risk
> there.
>
> There was probably a restriction about mx classes working on very old
> player versions that didn’t support some behavior or API, but Apache Flex
> only goes back to 10.1 or so and I don’t think you’ll find too many
> important differences.
>
> You could try making mx classes the base class for the Spark classes, so
> the Spark subclasses would add in the AdvancedStyleClient, but the guts of
> the work is all done in the mx base classes.
>
> -Alex
>
> On 6/9/15, 5:48 AM, "Peter Ginneberge" <p....@gmail.com> wrote:
>
>>
>>This may affect mx only projects (in FB at least) where spark related
>>swc's
>>are removed when selecting "mx only" as the project's component set.
>>
>>
>>On 9/06/2015 13:33, Mihai Chira wrote:
>>> I'm making lots of changes to SortField and Sort, and I'm realising
>>> that having two versions of these files is error prone and duplicates
>>> effort. From what I can see, the differences are:
>>>
>>> Between mx.collections.SortField and spark.collections.SortField:
>>> 1. lots of asdocs changes
>>> 2. spark version ignores the caseInsensitive option
>>> 3. spark version extends AdvancedStyleClient, and has some more
>>> functions for dealing with styles (like a "locale" style)
>>> 4. spark version uses a SortingCollator to compare strings, while mx
>>> version uses ObjectUtil.stringCompare(), which uses
>>> String.localeCompare(). Not sure how different these are.
>>> Apart from a couple of bug fixes applied to both (except the bugs I'm
>>> working on right now, which I currently only applied to the mx
>>> version), they both arrived from the Adobe donation with these
>>> differences.
>>>
>>> Between mx.collections.Sort and spark.collections.Sort:
>>> 1. again, lots of asdocs changes
>>> 2. again, spark version extends AdvancedStyleClient, and has some more
>>> functions for dealing with styles (like a "locale" style)
>>> 3. mx version uses Array.sortOn when it can, while spark version
>>> doesn't (in the sort() function)
>>> And the same as above, apart from a couple commits, they both came
>>> from the Adobe donation with these differences.
>>>
>>> Questions:
>>> 1. Can the spark versions be used with the mx components which
>>> currently use the mx versions of Sort and SortField? I.e.
>>> AdvancedDataGrid, DataGrid and DefaultCubeImpl. Or would there be
>>> problems about these new style functions, or other issues?
>>> 2. If we can get the above to work, can we get rid of the mx versions?
>>> I think it's really important to remove duplication, because all
>>> changes to one version (e.g. the ones that I'm now making to sorting)
>>> might have unintended consequences when ported to the other version
>>> (or, even worse, we'll simply forget to do it, and still keep the bug
>>> in the other version), and maintaining two almost identical sets of
>>> unit tests is just impractical - not only would we have to make
>>> changes and fixes in two places, but we'd also have to update two sets
>>> of unit tests each time.
>>>
>>> Thoughts?
>>>
>

Re: Can we unify spark and mx Sort and SortField?

[Alex Harui <ah...@adobe.com>]

Peter is correct that you want to be careful about having mx-only classes
depend on Spark classes.

And in the strictest sense, I suppose there is a chance that someone’s app
depends on a difference in behavior between ObjectUtil and
String.localeCompare, although I personally don’t think there is much risk
there.

There was probably a restriction about mx classes working on very old
player versions that didn’t support some behavior or API, but Apache Flex
only goes back to 10.1 or so and I don’t think you’ll find too many
important differences.
 
You could try making mx classes the base class for the Spark classes, so
the Spark subclasses would add in the AdvancedStyleClient, but the guts of
the work is all done in the mx base classes.

-Alex

On 6/9/15, 5:48 AM, "Peter Ginneberge" <p....@gmail.com> wrote:

>
>This may affect mx only projects (in FB at least) where spark related
>swc's 
>are removed when selecting "mx only" as the project's component set.
>
>
>On 9/06/2015 13:33, Mihai Chira wrote:
>> I'm making lots of changes to SortField and Sort, and I'm realising
>> that having two versions of these files is error prone and duplicates
>> effort. From what I can see, the differences are:
>>
>> Between mx.collections.SortField and spark.collections.SortField:
>> 1. lots of asdocs changes
>> 2. spark version ignores the caseInsensitive option
>> 3. spark version extends AdvancedStyleClient, and has some more
>> functions for dealing with styles (like a "locale" style)
>> 4. spark version uses a SortingCollator to compare strings, while mx
>> version uses ObjectUtil.stringCompare(), which uses
>> String.localeCompare(). Not sure how different these are.
>> Apart from a couple of bug fixes applied to both (except the bugs I'm
>> working on right now, which I currently only applied to the mx
>> version), they both arrived from the Adobe donation with these
>> differences.
>>
>> Between mx.collections.Sort and spark.collections.Sort:
>> 1. again, lots of asdocs changes
>> 2. again, spark version extends AdvancedStyleClient, and has some more
>> functions for dealing with styles (like a "locale" style)
>> 3. mx version uses Array.sortOn when it can, while spark version
>> doesn't (in the sort() function)
>> And the same as above, apart from a couple commits, they both came
>> from the Adobe donation with these differences.
>>
>> Questions:
>> 1. Can the spark versions be used with the mx components which
>> currently use the mx versions of Sort and SortField? I.e.
>> AdvancedDataGrid, DataGrid and DefaultCubeImpl. Or would there be
>> problems about these new style functions, or other issues?
>> 2. If we can get the above to work, can we get rid of the mx versions?
>> I think it's really important to remove duplication, because all
>> changes to one version (e.g. the ones that I'm now making to sorting)
>> might have unintended consequences when ported to the other version
>> (or, even worse, we'll simply forget to do it, and still keep the bug
>> in the other version), and maintaining two almost identical sets of
>> unit tests is just impractical - not only would we have to make
>> changes and fixes in two places, but we'd also have to update two sets
>> of unit tests each time.
>>
>> Thoughts?
>>

Re: Can we unify spark and mx Sort and SortField?

[Peter Ginneberge <p....@gmail.com>]

This may affect mx only projects (in FB at least) where spark related swc's 
are removed when selecting "mx only" as the project's component set.


On 9/06/2015 13:33, Mihai Chira wrote:
> I'm making lots of changes to SortField and Sort, and I'm realising
> that having two versions of these files is error prone and duplicates
> effort. From what I can see, the differences are:
>
> Between mx.collections.SortField and spark.collections.SortField:
> 1. lots of asdocs changes
> 2. spark version ignores the caseInsensitive option
> 3. spark version extends AdvancedStyleClient, and has some more
> functions for dealing with styles (like a "locale" style)
> 4. spark version uses a SortingCollator to compare strings, while mx
> version uses ObjectUtil.stringCompare(), which uses
> String.localeCompare(). Not sure how different these are.
> Apart from a couple of bug fixes applied to both (except the bugs I'm
> working on right now, which I currently only applied to the mx
> version), they both arrived from the Adobe donation with these
> differences.
>
> Between mx.collections.Sort and spark.collections.Sort:
> 1. again, lots of asdocs changes
> 2. again, spark version extends AdvancedStyleClient, and has some more
> functions for dealing with styles (like a "locale" style)
> 3. mx version uses Array.sortOn when it can, while spark version
> doesn't (in the sort() function)
> And the same as above, apart from a couple commits, they both came
> from the Adobe donation with these differences.
>
> Questions:
> 1. Can the spark versions be used with the mx components which
> currently use the mx versions of Sort and SortField? I.e.
> AdvancedDataGrid, DataGrid and DefaultCubeImpl. Or would there be
> problems about these new style functions, or other issues?
> 2. If we can get the above to work, can we get rid of the mx versions?
> I think it's really important to remove duplication, because all
> changes to one version (e.g. the ones that I'm now making to sorting)
> might have unintended consequences when ported to the other version
> (or, even worse, we'll simply forget to do it, and still keep the bug
> in the other version), and maintaining two almost identical sets of
> unit tests is just impractical - not only would we have to make
> changes and fixes in two places, but we'd also have to update two sets
> of unit tests each time.
>
> Thoughts?
>