GH Pages is likely the way to go. Maybe we could make the comparison an interactive Royale app… ;-)
> On Oct 3, 2017, at 11:18 PM, Alex Harui <[email protected]> wrote: > > 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 >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>>> >>> >> >
