My plan is to work through each major component and fill in gaps. For example, with mx.controls.Button, we can emulate that with TextButton as the base and add in the few missing pieces (eg, useHandCursor).
We should also create and use tests so that there's a uniform approach to building these out. I think a lot of current Flex projects can benefit from the work. Just need to get started. I'm still trying to figure out how to get the tests we have to run without errors! ‹peter On 2/28/18, 1:27 PM, "Alex Harui" <[email protected]> wrote: > > >On 2/28/18, 9:53 AM, "Piotr Zarzycki" <[email protected]> wrote: > >>Alex, >> >>I saw your response to Alina about writing emulation and contributing. >>However how does actually she meet with her deadlines ? To me it sounds >>like a lot of work, even if you and Peter help. How does emulations speed >>up the work ? >> >>Does rewriting one by one views won't be simply faster. > >I'm not sure which would be faster. If it was simple text replacement, >then just running sed would be faster, but I'm thinking it won't be simple >text replacement. There might be a "label" property on her MXML >components that shouldn't be changed to "text". And other MXML tags might >be replaced by sets of MXML tags and if you don't wrap those up into >components, then if you decide the replacement set was not right, you have >to go and find all of the other instances which can be tricky. > >Having recently done the rename from FlexJS to Royale, we just recently >found another problem in the text replacement. > >Also, if we come out with a set of emulations, it should make migration >easier for the next people who try to migrate. > >And finally, it allows us to help her migrate without us having to touch >her 500 MXML files. > >If there's a better way, speak up now. > >My 2 cents, >-Alex >> >>What do others think ? >> >>Thanks, Piotr >> >> >>2018-02-27 20:52 GMT+01:00 Alex Harui <[email protected]>: >> >>> >>> >>> On 2/27/18, 11:18 AM, "Harbs" <[email protected]> wrote: >>> >>> >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. >>> >>> Yeah, I can't guarantee it will be better, but having recently survived >>>a >>> huge search and replace to rename FlexJS to Royale, which included a >>> mistake only found a few days ago, this seems worth a try. >>> >>> Later, >>> -Alex >>> > >>> >> 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.pa >>> >>>tr >>> >>><https://na01.safelinks.protection.outlook.com/?url= >>> https%3A%2F%2Fwww.pa >>> >>>tr> >>> >>> eon.com >>> >>><https://na01.safelinks.protection.outlook.com/?url= >>> http%3A%2F%2Feon.com >>> >>>%2F&data=02%7C01%7Caharui%40adobe.com%7C14f2b02abdf14529768408d57e16 >>> e9d4 >>> >>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >>> 7C636553559236362115&sdata=m >>> >>>QT%2FmxbQYihs5OxQSivxPFhsngBEIR3dV6%2Bl7ysUp1o%3D&reserved=0>% >>> 2Fpiotrzar >>> >>>zycki&data=02%7C01%7Caharui%40adobe.com >>> >>><https://na01.safelinks.protection.outlook.com/?url= >>> http%3A%2F%2F40adobe >>> >>>.com%2F&data=02%7C01%7Caharui%40adobe.com% >>> 7C14f2b02abdf14529768408d57e16 >>> >>>e9d4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >>> 7C636553559236362115&sda >>> >>>ta=3aLPLQZnepcRuNWiYlf8qg%2B1UpNb0DoMfQHnMH%2FvL5w%3D& >>> reserved=0>%7Ca5c7 >>> >>>823f7f7442 >>> >>> >>> >>>fd0c8308d57e11d1d7%7Cfa7b1b5a7b34438794aed2c178de >>> cee1%7C0%7C0%7C63655353 >>> >>>73 >>> >>> >>> >>>61973461&sdata=LW%2FaHxwMi1FWWa%2BEDWiob1bVaZvS7LuF9aNlOmzgHrw >>> %3D&reserv >>> >>>ed >>> >>> =0 >>> >>> >>> >>><https://na01.safelinks.protection.outlook.com/?url= >>> https%3A%2F%2Fwww.pa >>> >>>tr >>> >>><https://na01.safelinks.protection.outlook.com/?url= >>> https%3A%2F%2Fwww.pa >>> >>>tr> >>> >>> eon.com >>> >>><https://na01.safelinks.protection.outlook.com/?url= >>> http%3A%2F%2Feon.com >>> >>>%2F&data=02%7C01%7Caharui%40adobe.com%7C14f2b02abdf14529768408d57e16 >>> e9d4 >>> >>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >>> 7C636553559236362115&sdata=m >>> >>>QT%2FmxbQYihs5OxQSivxPFhsngBEIR3dV6%2Bl7ysUp1o%3D&reserved=0>% >>> 2Fpiotrzar >>> >>>zycki&data=02%7C01%7Caharui%40adobe.com >>> >>><https://na01.safelinks.protection.outlook.com/?url= >>> http%3A%2F%2F40adobe >>> >>>.com%2F&data=02%7C01%7Caharui%40adobe.com% >>> 7C14f2b02abdf14529768408d57e16 >>> >>>e9d4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >>> 7C636553559236362115&sda >>> >>>ta=3aLPLQZnepcRuNWiYlf8qg%2B1UpNb0DoMfQHnMH%2FvL5w%3D& >>> reserved=0>%7Ca5c7 >>> >>>823f7f7442 >>> >>> >>> >>>fd0c8308d57e11d1d7%7Cfa7b1b5a7b34438794aed2c178de >>> cee1%7C0%7C0%7C63655353 >>> >>>73 >>> >>> >>> >>>61973461&sdata=LW%2FaHxwMi1FWWa%2BEDWiob1bVaZvS7LuF9aNlOmzgHrw >>> %3D&reserv >>> >>>ed >>> >>> =0>* >>> > >>> >>> >> >> >>-- >> >>Piotr Zarzycki >> >>Patreon: >>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pat >>r >>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C9ddf22cf0eb74 >>b >>967c5808d57ed42774%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636554372 >>1 >>69656425&sdata=M3DfCCotepk3%2BZaxuw4KN3qookAZ34lWZNjJca7gCPY%3D&reserved= >>0 >><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pat >>r >>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C9ddf22cf0eb74 >>b >>967c5808d57ed42774%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636554372 >>1 >>69656425&sdata=M3DfCCotepk3%2BZaxuw4KN3qookAZ34lWZNjJca7gCPY%3D&reserved= >>0 >>>* >
