royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: Flex Emulation SWCs
Date Tue, 27 Feb 2018 19:13:43 GMT
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> 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.patr
>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%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
>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca5c7823f7f7442
>fd0c8308d57e11d1d7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365535373
>61973461&sdata=LW%2FaHxwMi1FWWa%2BEDWiob1bVaZvS7LuF9aNlOmzgHrw%3D&reserved
>=0>*

Mime
View raw message