Definitely on the right path. I thought I’d try and copy this into the Github wiki, but wowsers! Tables are *hard* in Markdown, and it seems like multiline tables are hard or impossible on Github wiki pages. :-(
> On Oct 3, 2017, at 8:30 PM, Peter Ent <[email protected]> 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" <[email protected]> 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:[email protected]] >>> Envoyé : samedi 30 septembre 2017 07:56 >>> À : [email protected]; [email protected]; [email protected] >>> 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 >>> <[email protected]<mailto:[email protected]>> >>> Reply-To: "[email protected]<mailto:[email protected]>" >>> <[email protected]<mailto:[email protected]>> >>> Date: Friday, September 29, 2017 at 5:00 PM >>> To: "[email protected]<mailto:[email protected]>" >>> <[email protected]<mailto:[email protected]>>, >>> "[email protected]<mailto:[email protected]>" >>> <[email protected]<mailto:[email protected]>>, >>> "[email protected]<mailto:[email protected]>" >>> <[email protected]<mailto:[email protected]>> >>> 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 >>> <[email protected]<mailto:[email protected]>> 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" >>> <[email protected]<mailto:[email protected]>> 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" >>> <[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>] >>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À : >>>>>> [email protected]<mailto:[email protected]>; >>>>>> [email protected]<mailto:[email protected]> >>>>>> 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" >>>>>> <[email protected]<mailto:[email protected]>> >>>>>> 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:[email protected]<mailto:[email protected] >>>>>>>> m>] Envoyé : jeudi 28 septembre 2017 19:08 À : >>>>>>>> [email protected]<mailto:[email protected]> >>>>>>>> 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 >>>>>>>> <[email protected]<mailto:[email protected]>>: >>>>>>>> >>>>>>>>> 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 >>>>>>> >>>>> >>>>> >>>> >> >> >
