Gotcha. I’m not 100% convinced that it’s going to ultimately be easier like this, but it might be interesting to have a migration set and see how useful it actually is.
> On Feb 27, 2018, at 9:13 PM, Alex Harui <[email protected]> wrote: > > If we put trace statements in the API stubs, the user could get some > output that tells what is missing. Or scan the JS for some jsdoc key we > leave in the code. But if it compiles, the user will know also what is > missing because the App will not look right or operate correctly. > > Harbs, back when you migrated your app, there was no > spark.components.Button and we weren't sure we would ever build one, since > a complete implementation requires over 100 methods and properties. I'm > still not clear on exactly what steps you took to migrate, so, I am > imagining that for every s:Button or "import spark.components.Button" you > had to search and replace it with js:TextButton or "import > org.apache.royale.html.TextButton". So I'm guessing that you created a > spark.components.Button class that was all stubs so the app would compile > without having to convert every using of Spark Button, yet it would help > you find the remaining places to convert. > > I am proposing that we actually add an operational spark.components.Button > in a SWC that only implements the 12 out of the 100+ APIs that Alina > needs. Then there are fewer places to change in her code. The final > output will be bigger because we have this additional emulation code, but > it should get it up and running. So, the migration experience will be > quite different for Alina. You had to do a lot of search and replace with > bundles of beads. We are going to encapsulate that work under the API > surface. Maybe we don't need to have every migration user do that much > searching and replacing. Our goal is to try to encapsulate and eliminate > repetitive work where we can. > > As other users try to migrate, we'll get their API reports, see what is > missing and hopefully only need to add a few more APIs. > > Thoughts? > -Alex > > On 2/27/18, 10:42 AM, "Piotr Zarzycki" <[email protected] > <mailto:[email protected]>> wrote: > >> What would be the results for Alina if you will have that swc ? She simply >> will be able to launch application without the error - That's the idea ? >> >> 2018-02-27 19:38 GMT+01:00 Harbs <[email protected]>: >> >>> Maybe. Not sure. >>> >>> How does the client know what needs to be implemented and how do they go >>> about implementing that? >>> >>>> On Feb 27, 2018, at 8:32 PM, Alex Harui <[email protected]> >>> wrote: >>>> >>>> Hmm, maybe I'm not understanding you. If we decide to create a SWC >>> with >>> a >>>> spark.components.Button and Alina needs 12 APIs and we only have time >>>> right now to implement 6 of them, how would you handle the missing 6? >>>> >>>> I would just implement those APIs but they wouldn't do anything. They >>>> would contain a comment or trace statement or todo. I don't think I >>> would >>>> create a dummy/stub spark.components.Button class, just dummy/stub >>> methods >>>> and properties. >>>> >>>> Maybe we are saying the same thing? >>>> -Alex >>>> >>>> On 2/27/18, 10:15 AM, "Harbs" <[email protected]> wrote: >>>> >>>>> If things are no-op or to-dos wouldn’t “stubs” or “dummy” classes be >>>>> better? >>>>> >>>>> What’s the advantage of having partially functional SWCs? It seems >>> to me >>>>> like it would mask the issues? >>>>> >>>>> Harbs >>>>> >>>>>> On Feb 27, 2018, at 7:48 PM, Alex Harui <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> On the users list, Alina has provided the API report for the main >>>>>> portion >>>>>> of her application. We are still waiting to get a report on her SWC >>>>>> library. She might have a pile of modules to report on as well. >>>>>> >>>>>> Based just on the main application, and her saying that she has 500 >>> MXML >>>>>> files to port, I'm leaning towards creating migration SWCs that >>> reduce >>>>>> the >>>>>> amount of copy/paste. In her data, we see that only 12 out of more >>> than >>>>>> 100 APIs on s:Button are being used, and we have 6 of them >>> implemented >>>>>> already. The plan would be to write the remaining six. Some, like >>>>>> useHandCursor might be temporary no-ops or to-dos. >>>>>> >>>>>> I've been pondering what to name these libraries. I've been using >>>>>> MXish.SWC and Sparkish.SWC, but maybe we want a better name like >>>>>> MXMigration.SWC/SparkMigration.SWC or MXRoyale.SWC/SparkRoyale.SWC >>> or >>>>>> RoyaleMX/RoyaleSpark.SWC. I want to imply that it isn't fully >>> backward >>>>>> compatible in the name of the SWC if possible. >>>>>> >>>>>> We could leave the namespace URI as >>>>>> >>>>>> xmlns:s="library://ns.adobe.com/flex/spark" >>>>>> xmlns:mx="library://ns.adobe.com/flex/mx" >>>>>> >>>>>> >>>>>> just to have one less thing to change in each MXML file, although it >>>>>> might >>>>>> be better to use a different namespace URI to get "adobe.com" out of >>>>>> there >>>>>> which might help imply that it isn't fully backward compatible and >>> go >>>>>> with: >>>>>> >>>>>> xmlns:s="library://ns.apache.org/royale/spark" >>>>>> xmlns:mx="library://ns.apache.org/royale/mx" >>>>>> >>>>>> I don't think we'd bother to fully re-create the Flex class >>> hierarchy >>> at >>>>>> this time, but I think we will need to create a UIComponent that >>>>>> subclasses UIBase and have all migration components extend that >>> instead >>>>>> of >>>>>> extending Express or Basic components because we need to change the >>> way >>>>>> percentWidth/Height work in the migration components. UIBase sets >>> the >>>>>> style.width to a % value, but we don't want that in the migration >>>>>> components. The Flex layout classes use percentage differently. >>> The >>>>>> cool >>>>>> thing is that if we wrote our beads correctly, we can re-compose the >>>>>> functionality from Basic and Express onto this migration library >>> and it >>>>>> will "just work". This illustrates the value of composition over >>>>>> subclassing. >>>>>> >>>>>> >>>>>> I think it will be a few more days before we have all of the data >>> from >>>>>> Alina and know how big this task will be so now is a good time to >>>>>> discuss >>>>>> some of the details on how this would work. >>>>>> >>>>>> Thoughts? >>>>>> -Alex >>>>>> >>>>> >>>> >>> >>> >> >> >> -- >> >> Piotr Zarzycki >> >> Patreon: >> *https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr >> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr> >> eon.com <http://eon.com/>%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com >> <http://40adobe.com/>%7Ca5c7823f7f7442 >> fd0c8308d57e11d1d7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365535373 >> 61973461&sdata=LW%2FaHxwMi1FWWa%2BEDWiob1bVaZvS7LuF9aNlOmzgHrw%3D&reserved >> =0 >> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr >> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr> >> eon.com <http://eon.com/>%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com >> <http://40adobe.com/>%7Ca5c7823f7f7442 >> fd0c8308d57e11d1d7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365535373 >> 61973461&sdata=LW%2FaHxwMi1FWWa%2BEDWiob1bVaZvS7LuF9aNlOmzgHrw%3D&reserved >> =0>*
