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