OK, maybe wait until royale-docs is up and try GH Pages? Or if it is better as plain HTML, put it on royale.a.o?
-Alex On 10/3/17, 1:13 PM, "Harbs" <[email protected]> wrote: >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: >> >> >>https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fhome.apache >>.org%2F~pent%2FFlex2Royale%2F&data=02%7C01%7C%7C8a812742e9fc437f944508d50 >>a9b42ed%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636426584313172373&s >>data=NtSbdc6hLrusGzB5fiu%2FNsim0Xo5bNvQczCUvVmU40U%3D&reserved=0 >> >> 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 >>>>>>>> >>>>>> >>>>>> >>>>> >>> >>> >> >
