royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piotr Zarzycki <piotrzarzyck...@gmail.com>
Subject Re: Flex Emulation SWCs
Date Wed, 28 Feb 2018 17:53:04 GMT
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.

What do others think ?

Thanks, Piotr


2018-02-27 20:52 GMT+01:00 Alex Harui <aharui@adobe.com.invalid>:

>
>
> On 2/27/18, 11:18 AM, "Harbs" <harbs.lists@gmail.com> 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 <aharui@adobe.com.INVALID>
> >>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" <piotrzarzycki21@gmail.com
> >><mailto:piotrzarzycki21@gmail.com>> 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 <harbs.lists@gmail.com>:
> >>>
> >>>> 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 <aharui@adobe.com.INVALID>
> >>>> 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" <harbs.lists@gmail.com> 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 <aharui@adobe.com.INVALID>
> >>>>>>> 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://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message