Re: [Royale] Flex to FlexJS migration path

[Peter Ent <pe...@adobe.com.INVALID>]

I'm working on a sample page based on this idea. I hope to have at least
two different ways of presenting this information from which to choose. I
will publish it on my home.apache.org site as soon as it is completed.

—peter

On 9/30/17, 7:47 AM, "Idylog - Nicolas Granon" <ng...@idylog.com> wrote:

>Hi Alex and all,
>
>In my eyes (and in my dreams !), this migration helper table could be as
>simple as :
>
>+-------------------------------------------------------------------------
>-------------------------------------------------------------+
>|Flex component class			| Closest FlexJS equivalent	| Closest non-FlexJS
>equivalent (MDL...)	|Implementation hints		|
>+-------------------------------------------------------------------------
>-------------------------------------------------------------+
>|mx.containers.TabNavigator		| None (or empty)			| None (or
>empty)					|Extends xxx Implements xxx	|
>|spark.ButtonBar				|					| yyyyyy						|					|
>|spark.validator.NumberValidator	| yyyyyyy				|							|					|
>| etc.					|					|							|					|
>+-------------------------------------------------------------------------
>-------------------------------------------------------------+
>
>The "flex class" should point (link to) Flex API reference documentation
>
>The "closest FlexJS implementation" should link to FlexJS API reference
>documentation (or should it be "Apache Royale" ?)
>
>The "closest non-FlexJS" should in fact be "closest MDL equivalent" if
>MDL is the "official" additional UI library. We do not want to start
>opinion wars about "which is the best equivalent in the world" ! It
>should restrict only to one or two "official" (meaning
>FlexJS-recommended) libraries and not try to explore all available
>libraries.
>
>Implementation hints would be useful when there is really no close
>equivalent and give clues to developers as where to start in order to
>build a close equivalent.
>Or maybe "implementation hints" could link to some kind of wiki where
>contributors could discuss and express their opinions as there are
>usually several approaches.
>
>It would be better if there is some filter on flex package (or
>sub-package) and a search function also.
>Maybe it would be useful if there is a filter for showing only Flex
>component who have a FlexJS equivalent (excluding MDL equivalent, and no
>equivalent at all) and also an "inverse" filter (Flex component having
>only a MDL counterpart for those who want to stick to MDL).
>
>Basic ordering should be by package (like in the Flex reference docs).
>
>If there is a FlexJS implementation, it is not necessary to give a MDL
>implementation (?).
>If there is a FlexJS or a MDL implementation, implementation hints should
>be empty (?).
>
>I think this leads naturally to giving the "express" implementation as
>"closest FlexJS equivalent" because it would usually really be the
>"closest equivalent".
>The link to API reference documentation would allow to see how the
>"express" version is constructed and all the implementation details and
>examples (something very close to Flex API reference docs where
>interfaces and ancestors are readily readable).
>
>If closest equivalent is MDL, it might be difficult to have a link to
>specific doc page (since it is outside Flex and FlexJS docs, and could
>change without notice). May be a global MDL docs entry link in the side
>bar is the best option...
>
>Maybe a "discussion" link (on each line) would be interesting : it could
>lead to a page where implementers and developers could share their
>experience on a component-by-component basis, share their customization
>tips etc.
>I'm not sure if this is different from "implementation hints"... In my
>mind "implementation hints" is really about components who do not really
>have an equivalent. "Discussion" is more about usage/customization
>experience or existing equivalents.
>
>Maybe the "closest implementation" columns could be merged and an icon
>would indicate if this closest implementation sits in the FlexJS/Royale
>world or the MDL world.
>(is "Apache Royale" the new designation of "FlexJS" ? And should I drop
>entirely "FlexJS" from my posts ?)
>
>The "Flex" column could (should) be directly constructed from existing
>Flex reference docs.
>
>It would also be very useful for non-UI classes (XML, FileReference,
>Formatters,Remoting etc...), showing possible "holes" in JS
>implementation.
>
>It probably should link to Flex Apache docs... it is more logical since
>they contains at least the same information as Adobe docs and they are
>supposed to be more up-to-date than Adobe docs.
>
>Maybe, for classes who *cannot* have an equivalent class (for conceptual
>reasons), the link (in "Implementation hints") should explain why, in the
>JS/HTML world, an implementation is useless/meaningless.
>
>Of course, there are situations where it is not really possible to map
>components one-to-one (maybe, for example, because two distinct Flex
>components are composited in only one MDL component). This should not be
>a big deal with the help of one or two lines of comments.
>
>Hope this helps,
>
>Regards,
>
>Nicolas Granon
>
>
>
>> -----Message d'origine-----
>> De : Alex Harui [mailto:aharui@adobe.com.INVALID]
>> Envoyé : samedi 30 septembre 2017 07:56
>> À : users@royale.apache.org; users@flex.apache.org; ngranon@idylog.com
>> Objet : Re: [Royale] Flex to FlexJS migration path
>> 
>> It wouldn't be a bad idea for more than one person to try to present
>> this comparison.  Then we can see which presentation(s) are useful and
>> iterate towards a final solution or solutions.
>> 
>> My personal philosophy is to try to not disappoint, so having Basic in
>> a list and finding out later it requires a lot of configuration or
>> doesn't have some important APIs may not be as good an approach as just
>> comparing Express, which should compare more favorably.
>> 
>> My 2 cents,
>> -Alex
>> 
>> From: Piotr Zarzycki
>> <pi...@gmail.com>>
>> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
>> <us...@royale.apache.org>>
>> Date: Friday, September 29, 2017 at 5:00 PM
>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>> <us...@royale.apache.org>>,
>> "users@flex.apache.org<ma...@flex.apache.org>"
>> <us...@flex.apache.org>>,
>> "ngranon@idylog.com<ma...@idylog.com>"
>> <ng...@idylog.com>>
>> Subject: Re: [Royale] Flex to FlexJS migration path
>> 
>> 
>> Hmm..But I was in my mind something simple. If we just show the names -
>> without to much details - even Basic can landed onto that table. Once
>> user see names will be able to look himself into that.
>> 
>> Piotr
>> 
>> On Sat, Sep 30, 2017, 00:22 Alex Harui
>> <ah...@adobe.com>> wrote:
>> IMO, we want to compare the Express and maybe MDL packages against
>> Flex's Spark and MX.  Comparing Basic components will be too difficult
>> because of how configurable they are.  And this might inspire us to
>> create a Migration component set that is better tuned to ease
>> migration.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 9/29/17, 11:40 AM, "Peter Ent"
>> <pe...@adobe.com>> wrote:
>> 
>> >Hi,
>> >
>> >I'm moving to discussion over to Royale, but still including users
>> from
>> >flex who have not yet subscribed to the new Royale email lists.
>> >
>> >I was speaking with Alex earlier and we thought the idea of a
>> >comparison table was a good one. I've been giving some thought to what
>> >this might look like and how complex it should (and it could) be.
>> >
>> >Take for example, Panel. Both Flex and Royale have a Panel. There are
>> >some differences and, being a developer myself, I'd like at least a
>> >quick comparison so I would know how to convert any uses of Panel such
>> >as MXML attribute differences and such.
>> >
>> >Using TextInput as another example, the Royale TextInput has far few
>> >options, but things like password security can be added as beads.
>> >
>> >We were also thinking of an app that would dive into the ASDocs and
>> >present a side-by-side, where possible, comparison. That would be a
>> bit
>> >of a project.
>> >
>> >Please share your thoughts.
>> >
>> >Regards,
>> >Peter Ent
>> >Adobe Systems/Apache Royale Project
>> >
>> >On 9/28/17, 6:43 PM, "Idylog - Nicolas Granon"
>> <ng...@idylog.com>> wrote:
>> >
>> >>Many thanks for your comments and thoughts,
>> >>
>> >>(this thread is a follow-up of "[FlexJS] Guidelines for
>> implementation
>> >>of layout containers and navigation containers" but I felt that the
>> >>topic was getting more general).
>> >>
>> >>(May I remind to the readers that my company is not very interested
>> in
>> >>keeping a "dual output" (SWF/JS) from FlexJS. We believe that FlexJS
>> >>should concentrate on outputting JS, and JS only, from AS3 and MXML
>> code.
>> >>We also believe that MXML/AS3 project directed to AIR should stay
>> >>under the Flex umbrella (not FlexJS). It is however interesting if
>> >>library
>> >>(modules/SWC) project can have dual output, but it is not mandatory.
>> >>Our opinions do not reflect all the use-cases of the Flex community!
>> >>We will be happy to hear from other people and differing opinions).
>> >>
>> >>I have to say that it is really a pleasure to have that kind of
>> >>discussion and that your height of view is quite amazing (I'm not
>> sure
>> >>that "height of view" is a correct English expression ??? Please
>> >>excuse my bad English).
>> >>
>> >>We, at Idylog - and others - have obviously strong calendar
>> constraints.
>> >>We can expect a real decrease in Flash Player support from browser
>> >>editors in the next 12 months, well before Adobe end of support.
>> >>
>> >>Add to that all the apple-fan crowd (and others) being so happy that
>> >>Flash Player is - at last - sent to the grave (I have read such
>> papers).
>> >>And all the people who do not even know that Flex exists, is based on
>> >>FP, and is used for day to day operations in hundreds (thousands ?)
>> of
>> >>companies but are sooo happy that FP will finally disappear..
>> >>
>> >>I am pretty sure that running FP on our customers' workstations will
>> >>be _very_ problematic well before Dec. 2020.
>> >>
>> >>In my company alone (and it's a tiny company!) two of my customers
>> >>have already shown signs of nervousness. And every time there is a
>> >>small glitch in one of our software, I immediately receive a call
>> like
>> >>"We had this problem because FP is over and your are keeping us in
>> >>obsolete technology" !! No kidding.
>> >>
>> >>That said, I am a big fan of Flex (and FlexJS) and AS3.
>> >>I believe that the fact that the language is *less* permissive and
>> >>*less* flexible than JS is in fact a very good thing for the kind of
>> >>software that we, at IdyLog, develop.
>> >>
>> >>But, to quote a popular series, "we are running out of time".
>> >>
>> >>I fully understand that you value "independence from layers of
>> >>management". I understand that you want to give power of decision to
>> >>everyone. It is a great and noble goal.
>> >>And I fully support it in the domains of education, civil rights,
>> >>freedom of thought/speech, criticism, politics, artistic creativity,
>> >>academic research... everything intellectual and/or related to
>> >>personal life but away from economic/profits concerns.
>> >>
>> >>The reality of my kind of company is : can I deliver an operational,
>> >>functional, reliable, cheap solution in 5 weeks from scratch ? (or,
>> as
>> >>an architect, since we like to think about us as "digital architects"
>> >>: can I have this house build in 12 months from scratch and under
>> >>budget ? And we are not talking about building the next Chicago Art
>> >>Museum ! Just an ordinary house !). That is why we cannot live
>> without
>> >>a reliable "faucet catalog" (and windows, and doors, and stairs and
>> >>ready-to-use concrete formula and tiles etc.).
>> >>
>> >>We try to think "craftsmen" when we are in the conception phase, and
>> >>think "industrial" when building the software (ever heard of
>> >>"maintenance fees" from an architect ? Not me !).
>> >>
>> >>I would be quite happy if FlexJS could provide us with a reliable
>> >>migration path (especially regarding UI components).
>> >>
>> >>As an example, it would be VERY useful to have a table showing, for
>> >>each class from Flex SDK (that's a lot !),
>> >>- the corresponding flexJS class if any (same API, same
>> functionality,
>> >>the class name might be identical or different)
>> >>- if no corresponding class, the equivalent FlexJS class (with a
>> >>detailed enumeration of differences between the two, plus examples,
>> >>and for each strand, all the available beads)
>> >>- if no equivalent, a suggested best-fit equivalent from an existing
>> >>third-party JS library (with a short enumeration of differences)
>> >>- if none of the above is available, a suggestion on how an
>> equivalent
>> >>class could be constructed (inheritance/composition clues)
>> >>- the Flex SDK version number of the original class + link to
>> >>reference docs
>> >>- the FlexJS SDK version number of the target class + link to
>> >>reference docs
>> >>
>> >>(I wrote "class", it obviously applies to interfaces too).
>> >>
>> >>For each FlexJS "equivalent" class, it should read :
>> >>- whether the equivalent is JS only, or JS/SWF, or SWF only
>> >>
>> >>Such a document would be a great help in migration.
>> >>
>> >>Best regards,
>> >>
>> >>Nicolas Granon
>> >>
>> >>
>> >>
>> >>
>> >>> -----Message d'origine-----
>> >>> De : Alex Harui
>> >>> [mailto:aharui@adobe.com.INVALID<ma...@adobe.com.INVALID>]
>> >>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>> >>> users@flex.apache.org<ma...@flex.apache.org>;
>> >>> ngranon@idylog.com<ma...@idylog.com>
>> >>> Objet : Re: [FlexJS] Guidelines for implementation of layout
>> >>> containers and navigation containers
>> >>>
>> >>> Hi Nicolas,
>> >>>
>> >>> The Application developer is not required to use composition.  They
>> >>> are most welcome to use inheritance just like in regular Flex and
>> in
>> >>> fact, the MXML component workflow is the same as regular Flex and
>> >>> based on inheritance.
>> >>>
>> >>> You are correct about the Faucet analogy.  Faucet developers are
>> >>> Component developers in FlexJS are are encouraged to compose new
>> >>> faucets out of different smaller pieces (choose a metal, choose a
>> >>> handle, choose pipe size).  What we don't have is a shopping
>> catalog
>> >>> of faucets (popular
>> >>> components) mainly because we are too new to have any metrics about
>> >>> popularity.  If you choose FlexJS you will be one of our first
>> >>> reviewers.
>> >>>
>> >>> For sure, React has much better support right now because it has
>> the
>> >>> money to pay people to do it.  Apache projects are
>> >>> volunteer/community driven, not corporation driven, and in our case
>> >>> we don't have the money and need folks to pitch in.  In return for
>> >>> pitching in, you get more control.  You get to have the bugs fixed
>> >>> you need fixed if you know how to fix them, no layers of management
>> in your way.
>> >>>
>> >>> HTH,
>> >>> -Alex
>> >>>
>> >>> On 9/28/17, 12:43 PM, "Idylog - Nicolas Granon"
>> >>> <ng...@idylog.com>>
>> >>> wrote:
>> >>>
>> >>> >Hi Piotr,
>> >>> >
>> >>> >Many thanks for your help.
>> >>> >
>> >>> >We are not interested *at all* in SWF compatibility or alignment
>> >>> >between a SWF and a JS version.
>> >>> >Our goal is to migrate our browser-based applications catalog out
>> >>> >of Flash player. We will keep AIR apps (desktop/mobile) under the
>> >>> Flex/AIR
>> >>> >hood. Common libraries (which usually do not have any UI) will be
>> >>> >upgraded to mixed-mode when necessary (and if possible ! If not
>> >>> >possible
>> >>> >- or too complicated - we will have two versions, of for SWF, and
>> >>> >one for JS).
>> >>> >
>> >>> >So maybe our best bet is to work on the integration of existing
>> JS-
>> >>> only
>> >>> >UI components... (MDL, jQuery etc.)
>> >>> >
>> >>> >It would be nice if we had some clues about which JS UI library
>> (or
>> >>> >libraries) would be the closest to Flex-SWF components in terms of
>> >>> >functionalities.
>> >>> >
>> >>> >(we would not like to have to pick from half a dozen different
>> >>> >libraries ! We like things simple and powerful !).
>> >>> >
>> >>> >We found Sensha UI libraries very nice, but wayyyy too expensive
>> >>> >(but we do not mind paying a reasonable license price).
>> >>> >
>> >>> >We develop only enterprise management software (no games, no
>> >>> "personal"
>> >>> >utilities) and the components that we use the most are Datagrid,
>> >>> >HierarchicalDatagrid (very important), Forms (FormItem etc.),
>> >>> >Validators (and custom validators), DropdownList... I will not
>> >>> >enumerate all of them but you understand our needs... Localization
>> >>> >is also very important to us
>> >>> >(ResourceManager) and also quick and flexible layout management
>> >>> >(but
>> >>> we
>> >>> >never use "custom" layouts).
>> >>> >On the other hand, visual skinning is not the most important
>> thing.
>> >>> >In our world, the most important thing is reliability,
>> performance,
>> >>> >and ease of use. Cosmetics comes at the bottom of our wishlist
>> >>> >(even if it is somehow related to ease of use).
>> >>> >
>> >>> >Another problem we face (for custom components) is dealing with
>> >>> >composition vs inheritance.
>> >>> >The concept is *intellectually* cleaner. No doubt about this.
>> >>> >But for the conceptors/implementors, what was initially very
>> simple
>> >>> >(find the closest existing component, extend it, override what you
>> >>> need
>> >>> >to, add missing parts) suddenly becomes very very complicated
>> >>> >because you have to guess what are the existing parts you should
>> >>> >assemble
>> >>> >(compose) among the hundreds of existing parts...(some of them
>> >>> >already composed...!). In the "classic" Flex world, component
>> >>> >compositing was used for...composed components ! (components with
>> >>> >multiple functional
>> >>> >"areas")  Not for standalone components.
>> >>> >We feel like a contractor building a house, who needs to install
>> >>> >and tweak a faucet, and instead of having to choose between four
>> >>> >"kind" of faucets we suddenly have to imagine and assemble a
>> >>> >never-seen-before faucet by choosing between all possible kinds of
>> >>> >pipes, all possible kinds of rubber, all possible kinds of metal,
>> >>> >all possible kinds of knobs...
>> >>> >
>> >>> >I would like to say that our job is not to *build* tools but to
>> >>> >*choose* tools in order to build usable software solutions. We are
>> >>> >"house contractors", not "faucet contractors". We need a "faucet
>> >>> >catalog" (UI
>> >>> >library) with well defined characteristics. If necessary, we can
>> >>> >slightly tweak it (custom item renderer is the most common need).
>> >>> >
>> >>> >Meanwhile, we are also testing ReactJS (although not a real
>> >>> >framework but, again, our main issue is the UI part) and I must
>> say
>> >>> >that documentation, samples, contribution and community activity
>> is
>> >>> >very impressive...(not event talking about robustness and
>> >>> >performance). At some point, rewriting our business logic in
>> >>> >TypeScript (yes, we are testing with TypeScript because we want to
>> >>> >stick to strongly typed code, classes...etc... and it works
>> >>> >surprisingly well) might prove
>> >>> more
>> >>> >reliable, and not necessary more expensive... I personally prefers
>> >>> >AS3 over TypeScript (easier to read, no "fancy" syntax, cleaner
>> >>> >handling
>> >>> of
>> >>> >"this"...) but TS is not bad at all.
>> >>> >
>> >>> >But we are going on in our tests and give a try to MDL (or
>> another)
>> >>> >+ flexJS.
>> >>> >
>> >>> >Best regards,
>> >>> >
>> >>> >Nicolas Granon
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >> -----Message d'origine-----
>> >>> >> De : Piotr Zarzycki
>> >>> >>
>> [mailto:piotrzarzycki21@gmail.com<mailto:piotrzarzycki21@gmail.co
>> >>> >> m>] Envoyé : jeudi 28 septembre 2017 19:08 À :
>> >>> >> users@flex.apache.org<ma...@flex.apache.org>
>> >>> >> Objet : Re: [FlexJS] Guidelines for implementation of layout
>> >>> >> containers and navigation containers
>> >>> >>
>> >>> >> Hi Nicolas,
>> >>> >>
>> >>> >> I believe my answer will only partially satisfy you. About
>> >>> containers
>> >>> >> exists in FlexJS (Royale) you can read more here [1]. I would
>> >>> >> strongly suggest look first on our examples [2]. We do not have
>> >>> >> ViewStack container, so I believe that is something which can be
>> >>> >> implemented and maybe pushed to our repository. We definitely
>> >>> >> suffer for a lack of documentation, when I was started to dig
>> >>> >> into the framework I simply look into how actually each
>> component
>> >>> >> is implemented [3] - architecture is pretty clean in my opinion
>> >>> >> and
>> >>> more
>> >>> >> composition oriented than inheritance. Quite helpful can be this
>> >>> >> website [4] - That is the slight description about our main
>> >>> principle PAYG.
>> >>> >>
>> >>> >> As for the components itself there are module Basic [3] which
>> >>> >> contains our native components which should look same in SWF and
>> >>> >> JS, but as you probably know it is not fully true and not
>> >>> >> necessary
>> >>> should be.
>> >>> >>
>> >>> >> There is also module MDL [5][6][7][8] which is wrapper around
>> >>> >> existing components + some implementation of some additional
>> >>> >> things like "dataProvider" in List. Encourage you to look into
>> >>> >> the code of components as I suggested it for Basic. This module
>> >>> >> do not have SWF representation - it is simply compile to JS
>> only.
>> >>> >>
>> >>> >>  I hope we will be better and better with documentation and some
>> >>> >> day new users will not have to dig into the code. I can say also
>> >>> >> from my experience that once you will figure out how everything
>> >>> >> is working productivity is quite good.
>> >>> >>
>> >>> >> [1]
>> >>> >>
>> >>>
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc
>> >>> >>wik
>> >>> i
>> >>> >>.ap
>> >>>
>> >>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%3
>> >>>
>> >>A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788
>> >>>
>> >>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&s
>> >>>
>> >>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>%
>> >>> >>2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d
>> >>> a
>> >>> >>ta=
>> >>>
>> >>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794
>> >>> >>aed
>> >>> 2
>> >>> >>c17
>> >>>
>> >>8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3Xru
>> >>> >>u84
>> >>> A
>> >>> >>q88
>> >>> >>7xFTPSj2DuB%2B0%3D&reserved=0
>> >>> >> es+and+Layouts
>> >>> >> [2]
>> >>>
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
>> >>> >>ith
>> >>> u
>> >>> >>b.c
>> >>> >>om%2Fapache%2Froyale-
>> >>> asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs&data=02
>> >>> >>%7C
>> >>>
>> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c
>> >>> >>178
>> >>> d
>> >>> >>ece
>> >>>
>> >>e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR6MD
>> >>> >>c%2
>> >>> B
>> >>> >>t1Y
>> >>> >>YMHGPVL7jA%3D&reserved=0
>> >>> >> [3]
>> >>> >>
>> >>>
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
>> >>> >>ith
>> >>> u
>> >>> >>b.c
>> >>> >>om%2Fapache%2Froyale-
>> >>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>> >>> >>88%
>> >>>
>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sd
>> >>> >>ata
>> >>> =
>> >>> >>xB2
>> >>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>> >>> >>
>> >>>
>> >>asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apac
>> >>> >>he/
>> >>> f
>> >>> >>l
>> >>> >> ex/html
>> >>> >> [4]
>> >>> >>
>> >>>
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc
>> >>> >>wik
>> >>> i
>> >>> >>.ap
>> >>>
>> >>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%3
>> >>>
>> >>A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788
>> >>>
>> >>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&s
>> >>>
>> >>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>%
>> >>> >>2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat
>> >>> a
>> >>> >>=02
>> >>>
>> >>%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794ae
>> >>> >>d2c
>> >>> 1
>> >>> >>78d
>> >>>
>> >>ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7a8l
>> >>> >>QTz
>> >>> L
>> >>> >>8KG
>> >>> >>N7kM0uCu2z4%3D&reserved=0
>> >>> >> 28
>> >>> >> [5]
>> >>> >>
>> >>>
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
>> >>> >>ith
>> >>> u
>> >>> >>b.c
>> >>> >>om%2Fapache%2Froyale-
>> >>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>> >>> >>88%
>> >>>
>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sd
>> >>> >>ata
>> >>> =
>> >>> >>xB2
>> >>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>> >>> >>
>> >>>
>> >>asjs/tree/develop/frameworks/projects/MaterialDesignLite/src/main/
>> >>> >>fle
>> >>> x
>> >>> >>/
>> >>> >> org/apache/flex/mdl
>> >>> >> [6]
>> >>> >>
>> >>>
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
>> >>> >>ith
>> >>> u
>> >>> >>b.c
>> >>> >>om%2Fapache%2Froyale-
>> >>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>> >>> >>88%
>> >>>
>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sd
>> >>> >>ata
>> >>> =
>> >>> >>xB2
>> >>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>> >>> >> asjs/tree/develop/examples/flexjs/MDLExample
>> >>> >> [7]
>> >>>
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
>> >>> >>etm
>> >>> d
>> >>> >>l.i
>> >>>
>> >>o%2Fcomponents%2Findex.html&data=02%7C01%7C%7Cab4e20a981d44a9ea014
>> >>> >>08d
>> >>> 5
>> >>> >>06a
>> >>>
>> >>92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183
>> >>> >>624
>> >>> &
>> >>> >>sda
>> >>>
>> >>ta=U6IQ%2Fikcn61Row6PjP%2FLF%2F4kqle2pe4U%2BEgAuxMfL90%3D&reserved
>> >>> >>=0
>> >>> >> [8]
>> >>> >>
>> >>>
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc
>> >>> >>wik
>> >>> i
>> >>> >>.ap
>> >>>
>> >>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%3
>> >>>
>> >>A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788
>> >>>
>> >>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&s
>> >>>
>> >>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>%
>> >>> >>2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data
>> >>> =
>> >>> >>02%
>> >>>
>> >>7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed
>> >>> >>2c1
>> >>> 7
>> >>> >>8de
>> >>>
>> >>cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xRtJr
>> >>> >>dXn
>> >>> D
>> >>> >>Lai
>> >>> >>3UM8LpiO7APc%3D&reserved=0
>> >>> >>
>> >>> >> Thanks, Piotr
>> >>> >>
>> >>> >>
>> >>> >> 2017-09-28 17:58 GMT+02:00 Idylog - Nicolas Granon
>> >>> >> <ng...@idylog.com>>:
>> >>> >>
>> >>> >> > We need to « re-implement » a ViewStack container component
>> >>> >> > class for use in a FlexJS (test) project.
>> >>> >> >
>> >>> >> > Is there a general walkthrough explaining (in details) the
>> >>> >> > principles when creating a container component for FlexJS (we
>> >>> >> > are mostly interested in the js output, not SWF).
>> >>> >> >
>> >>> >> > We have read the docs at
>> >>> >> >
>> >>>
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc
>> >>> >>wik
>> >>> i
>> >>> >>.ap
>> >>>
>> >>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%3
>> >>>
>> >>A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788
>> >>>
>> >>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&s
>> >>>
>> >>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>%
>> >>> >>2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0
>> >>> 2
>> >>> >>%7C
>> >>>
>> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c
>> >>> >>178
>> >>> d
>> >>> >>ece
>> >>>
>> >>e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoLzLH
>> >>> >>c8v
>> >>> u
>> >>> >>tx5
>> >>> >>PB%2Btmt94%3D&reserved=0
>> >>> >> > but it is rather control-oriented  (textInput, SliderŠ).
>> >>> >> >
>> >>> >> > We also plan to have TabNavigator etc. but I believe that we
>> >>> >> > can recreate a ViewStack container, creating other containers
>> >>> >> > won¹t be so
>> >>> >> difficult.
>> >>> >> >
>> >>> >> > Also, is there some document around explaining how to
>> implement
>> >>> >> layout
>> >>> >> > containers ? (as opposed to navigation containers).
>> >>> >> >
>> >>> >> > Or maybe we do not have the correct approach and
>> reimplementing
>> >>> >> > MX components does not fit in the ³FlexJS² philosophy ?
>> >>> >> >
>> >>> >> > Many thanks in advance
>> >>> >> >
>> >>> >> > Nicolas Granon
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >>
>> >>> >> Piotr Zarzycki
>> >>> >>
>> >>> >> mobile: +48 880 859 557
>> >>> >> skype: zarzycki10
>> >>> >>
>> >>> >> LinkedIn:
>> >>>
>> >>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
>> >>> >>w.l
>> >>> i
>> >>> >>nke
>> >>>
>> >>din.com<https://na01.safelinks.protection.outlook.com/?url=http%3A
>> >>>
>> >>%2F%2Fdin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788%7
>> >>>
>> >>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&sda
>> >>>
>> >>ta=B7M%2BhYPAUN%2FwIEe4DoMPpIjTZhxpwoTlKNrD%2FZaqkAg%3D&reserved=0
>> >>> >>>%2Fpiotrzarzycki&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a
>> >>> 9
>> >>> >>268
>> >>>
>> >>8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&
>> >>> >>sda
>> >>> t
>> >>> >>a=S
>> >>> >>ggb%2FVIn%2B0dBskPJ%2BZfJtXnRRrATLh1SHlamyGV58zM%3D&reserved=0
>> >>> >>
>> >>>
>> >><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpl.
>> >>> l
>> >>> >>ink
>> >>>
>> >>edin.com<https://na01.safelinks.protection.outlook.com/?url=http%3
>> >>>
>> >>A%2F%2Fedin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788
>> >>>
>> >>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&s
>> >>>
>> >>data=7rUvU4thZJ3Ja1S4aMg4RwxKGwoMgN4%2FIZ4RY9W4MwE%3D&reserved=0>%
>> >>> >>2Fin%2Fpiotr-zarzycki-
>> >>> 92a53552&data=02%7C01%7C%7Cab4e20a981d4
>> >>> >>4a9
>> >>>
>> >>ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636
>> >>> >>422
>> >>> 2
>> >>> >>459
>> >>>
>> >>42183624&sdata=tSGDWZ5AhBPECbf1%2Fy9R2u9N4qwJ03VBhzwzNsPTcCM%3D&re
>> >>> >>ser
>> >>> v
>> >>> >>ed=
>> >>> >>0>
>> >>> >>
>> >>> >> GitHub:
>> >>>
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
>> >>> >>ith
>> >>> u
>> >>> >>b.c
>> >>>
>> >>om%2Fpiotrzarzycki21&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a
>> >>> >>926
>> >>> 8
>> >>> >>8%7
>> >>>
>> >>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sda
>> >>> >>ta=
>> >>> l
>> >>> >>Mum
>> >>> >>yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0
>> >>> >
>> >>
>> >>
>> >
>
>