This looks good so far. Based on the information in it, this will be a larger page. But it definitely adds clarity.
-Mark K On Tue, Oct 3, 2017 at 1:30 PM, Peter Ent <p...@adobe.com.invalid> wrote: > I have a quick sample web page up at: > > http://home.apache.org/~pent/Flex2Royale/ > > I did not spend much time styling it and it is the first concept I thought > of after looking at the table below. I did not include yet where MDL might > come into play. There is a real estate issue in getting all of this > information onto the screen. > > I thought about what kind of information I would like to know when > considering to port, or actually porting, a Flex app to Royale. Key things > for me would be data binding and what components are available. Combining > ActionScript/MXML is essentially the same for Royale as it is for Flex. > > I put the stress on the Express package by making it the second column. In > this example I used Panel (which has no Express component yet) and > TextInput (which does have an Express version). This way people can see > how they would convert a TextInput into a Royale TextInput and let them > choose to either use the Express version or the Basic version. > > Give this some thought and let me know if you like the direction, want to > have other information included, do something else entirely, etc. > > Thanks, > 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 >>> >>> > >>> >> >>> >> >>> > >> >> >
