Re: Can we unify spark and mx Sort and SortField?
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?
On 6/21/15, 2:18 PM, Mihai Chira mihai.ch...@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?
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 mihai.ch...@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.ginnebe...@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 mark.kessler@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?
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 mark.kessler@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?
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?
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 mark.kessler@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?
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.ginnebe...@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 mark.kessler@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
Can we unify spark and mx Sort and SortField?
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?
On 6/9/15, 3:29 PM, Peter Ginneberge p.ginnebe...@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?
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 aha...@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.ginnebe...@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?
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?
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 aha...@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?
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 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.ginnebe...@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?
