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