flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Idylog - Nicolas Granon" <ngra...@idylog.com>
Subject RE: [Royale] Flex to FlexJS migration path
Date Sat, 30 Sep 2017 11:47:01 GMT
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
> <piotrzarzycki21@gmail.com<mailto:piotrzarzycki21@gmail.com>>
> Reply-To: "users@royale.apache.org<mailto:users@royale.apache.org>"
> <users@royale.apache.org<mailto:users@royale.apache.org>>
> Date: Friday, September 29, 2017 at 5:00 PM
> To: "users@royale.apache.org<mailto:users@royale.apache.org>"
> <users@royale.apache.org<mailto:users@royale.apache.org>>,
> "users@flex.apache.org<mailto:users@flex.apache.org>"
> <users@flex.apache.org<mailto:users@flex.apache.org>>,
> "ngranon@idylog.com<mailto:ngranon@idylog.com>"
> <ngranon@idylog.com<mailto:ngranon@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
> <aharui@adobe.com<mailto:aharui@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"
> <pent@adobe.com<mailto:pent@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"
> <ngranon@idylog.com<mailto:ngranon@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<mailto:aharui@adobe.com.INVALID>]
> >>> Envoyé : jeudi 28 septembre 2017 22:32 À :
> >>> users@flex.apache.org<mailto:users@flex.apache.org>;
> >>> ngranon@idylog.com<mailto:ngranon@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"
> >>> <ngranon@idylog.com<mailto:ngranon@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<mailto:users@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
> >>> >> <ngranon@idylog.com<mailto:ngranon@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
> >>> >
> >>
> >>
> >



Mime
View raw message