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" <ngra...@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:aha...@adobe.com.INVALID] >> Envoyé : samedi 30 septembre 2017 07:56 >> À : us...@royale.apache.org; users@flex.apache.org; ngra...@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 >> <piotrzarzyck...@gmail.com<mailto:piotrzarzyck...@gmail.com>> >> Reply-To: "us...@royale.apache.org<mailto:us...@royale.apache.org>" >> <us...@royale.apache.org<mailto:us...@royale.apache.org>> >> Date: Friday, September 29, 2017 at 5:00 PM >> To: "us...@royale.apache.org<mailto:us...@royale.apache.org>" >> <us...@royale.apache.org<mailto:us...@royale.apache.org>>, >> "users@flex.apache.org<mailto:users@flex.apache.org>" >> <users@flex.apache.org<mailto:users@flex.apache.org>>, >> "ngra...@idylog.com<mailto:ngra...@idylog.com>" >> <ngra...@idylog.com<mailto:ngra...@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 >> <aha...@adobe.com<mailto:aha...@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" >> <p...@adobe.com<mailto:p...@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" >> <ngra...@idylog.com<mailto:ngra...@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:aha...@adobe.com.INVALID<mailto:aha...@adobe.com.INVALID>] >> >>> Envoyé : jeudi 28 septembre 2017 22:32 À : >> >>> users@flex.apache.org<mailto:users@flex.apache.org>; >> >>> ngra...@idylog.com<mailto:ngra...@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" >> >>> <ngra...@idylog.com<mailto:ngra...@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:piotrzarzyck...@gmail.com<mailto:piotrzarzyck...@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 >> >>> >> <ngra...@idylog.com<mailto:ngra...@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 >> >>> > >> >> >> >> >> > > >
