Hi Nicolas, The Application developer is not required to use composition. They are most welcome to use inheritance just like in regular Flex and in fact, the MXML component workflow is the same as regular Flex and based on inheritance.
You are correct about the Faucet analogy. Faucet developers are Component developers in FlexJS are are encouraged to compose new faucets out of different smaller pieces (choose a metal, choose a handle, choose pipe size). What we don't have is a shopping catalog of faucets (popular components) mainly because we are too new to have any metrics about popularity. If you choose FlexJS you will be one of our first reviewers. For sure, React has much better support right now because it has the money to pay people to do it. Apache projects are volunteer/community driven, not corporation driven, and in our case we don't have the money and need folks to pitch in. In return for pitching in, you get more control. You get to have the bugs fixed you need fixed if you know how to fix them, no layers of management in your way. HTH, -Alex On 9/28/17, 12:43 PM, "Idylog - Nicolas Granon" <ngra...@idylog.com> wrote: >Hi Piotr, > >Many thanks for your help. > >We are not interested *at all* in SWF compatibility or alignment between >a SWF and a JS version. >Our goal is to migrate our browser-based applications catalog out of >Flash player. We will keep AIR apps (desktop/mobile) under the Flex/AIR >hood. Common libraries (which usually do not have any UI) will be >upgraded to mixed-mode when necessary (and if possible ! If not possible >- or too complicated - we will have two versions, of for SWF, and one for >JS). > >So maybe our best bet is to work on the integration of existing JS-only >UI components... (MDL, jQuery etc.) > >It would be nice if we had some clues about which JS UI library (or >libraries) would be the closest to Flex-SWF components in terms of >functionalities. > >(we would not like to have to pick from half a dozen different libraries >! We like things simple and powerful !). > >We found Sensha UI libraries very nice, but wayyyy too expensive (but we >do not mind paying a reasonable license price). > >We develop only enterprise management software (no games, no "personal" >utilities) and the components that we use the most are Datagrid, >HierarchicalDatagrid (very important), Forms (FormItem etc.), Validators >(and custom validators), DropdownList... I will not enumerate all of them >but you understand our needs... Localization is also very important to us >(ResourceManager) and also quick and flexible layout management (but we >never use "custom" layouts). >On the other hand, visual skinning is not the most important thing. In >our world, the most important thing is reliability, performance, and ease >of use. Cosmetics comes at the bottom of our wishlist (even if it is >somehow related to ease of use). > >Another problem we face (for custom components) is dealing with >composition vs inheritance. >The concept is *intellectually* cleaner. No doubt about this. >But for the conceptors/implementors, what was initially very simple (find >the closest existing component, extend it, override what you need to, add >missing parts) suddenly becomes very very complicated because you have to >guess what are the existing parts you should assemble (compose) among the >hundreds of existing parts...(some of them already composed...!). In the >"classic" Flex world, component compositing was used for...composed >components ! (components with multiple functional "areas") Not for >standalone components. >We feel like a contractor building a house, who needs to install and >tweak a faucet, and instead of having to choose between four "kind" of >faucets we suddenly have to imagine and assemble a never-seen-before >faucet by choosing between all possible kinds of pipes, all possible >kinds of rubber, all possible kinds of metal, all possible kinds of >knobs... > >I would like to say that our job is not to *build* tools but to *choose* >tools in order to build usable software solutions. We are "house >contractors", not "faucet contractors". We need a "faucet catalog" (UI >library) with well defined characteristics. If necessary, we can slightly >tweak it (custom item renderer is the most common need). > >Meanwhile, we are also testing ReactJS (although not a real framework >but, again, our main issue is the UI part) and I must say that >documentation, samples, contribution and community activity is very >impressive...(not event talking about robustness and performance). At >some point, rewriting our business logic in TypeScript (yes, we are >testing with TypeScript because we want to stick to strongly typed code, >classes...etc... and it works surprisingly well) might prove more >reliable, and not necessary more expensive... I personally prefers AS3 >over TypeScript (easier to read, no "fancy" syntax, cleaner handling of >"this"...) but TS is not bad at all. > >But we are going on in our tests and give a try to MDL (or another) + >flexJS. > >Best regards, > >Nicolas Granon > > > > >> -----Message d'origine----- >> De : Piotr Zarzycki [mailto:piotrzarzyck...@gmail.com] >> Envoyé : jeudi 28 septembre 2017 19:08 >> À : users@flex.apache.org >> Objet : Re: [FlexJS] Guidelines for implementation of layout containers >> and navigation containers >> >> Hi Nicolas, >> >> I believe my answer will only partially satisfy you. About containers >> exists in FlexJS (Royale) you can read more here [1]. I would strongly >> suggest look first on our examples [2]. We do not have ViewStack >> container, so I believe that is something which can be implemented and >> maybe pushed to our repository. We definitely suffer for a lack of >> documentation, when I was started to dig into the framework I simply >> look into how actually each component is implemented [3] - architecture >> is pretty clean in my opinion and more composition oriented than >> inheritance. Quite helpful can be this website [4] - That is the slight >> description about our main principle PAYG. >> >> As for the components itself there are module Basic [3] which contains >> our native components which should look same in SWF and JS, but as you >> probably know it is not fully true and not necessary should be. >> >> There is also module MDL [5][6][7][8] which is wrapper around existing >> components + some implementation of some additional things like >> "dataProvider" in List. Encourage you to look into the code of >> components as I suggested it for Basic. This module do not have SWF >> representation - it is simply compile to JS only. >> >> I hope we will be better and better with documentation and some day >> new users will not have to dig into the code. I can say also from my >> experience that once you will figure out how everything is working >> productivity is quite good. >> >> [1] >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.ap >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&data= >>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c17 >>8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3Xruu84Aq88 >>7xFTPSj2DuB%2B0%3D&reserved=0 >> es+and+Layouts >> [2] >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c >>om%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs&data=02%7C >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178dece >>e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR6MDc%2Bt1Y >>YMHGPVL7jA%3D&reserved=0 >> [3] >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c >>om%2Fapache%2Froyale-&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688% >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=xB2 >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0 >> asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apache/fl >> ex/html >> [4] >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.ap >>ache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&data=02 >>%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178d >>ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7a8lQTzL8KG >>N7kM0uCu2z4%3D&reserved=0 >> 28 >> [5] >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c >>om%2Fapache%2Froyale-&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688% >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=xB2 >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0 >> asjs/tree/develop/frameworks/projects/MaterialDesignLite/src/main/flex/ >> org/apache/flex/mdl >> [6] >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c >>om%2Fapache%2Froyale-&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688% >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=xB2 >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0 >> asjs/tree/develop/examples/flexjs/MDLExample >> [7] >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgetmdl.i >>o%2Fcomponents%2Findex.html&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a >>92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sda >>ta=U6IQ%2Fikcn61Row6PjP%2FLF%2F4kqle2pe4U%2BEgAuxMfL90%3D&reserved=0 >> [8] >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.ap >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data=02% >>7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178de >>cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xRtJrdXnDLai >>3UM8LpiO7APc%3D&reserved=0 >> >> Thanks, Piotr >> >> >> 2017-09-28 17:58 GMT+02:00 Idylog - Nicolas Granon >> <ngra...@idylog.com>: >> >> > We need to « re-implement » a ViewStack container component class for >> > use in a FlexJS (test) project. >> > >> > Is there a general walkthrough explaining (in details) the principles >> > when creating a container component for FlexJS (we are mostly >> > interested in the js output, not SWF). >> > >> > We have read the docs at >> > >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.ap >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=02%7C >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178dece >>e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoLzLHc8vutx5 >>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%2Fwww.linke >>din.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a9268 >>8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=S >>ggb%2FVIn%2B0dBskPJ%2BZfJtXnRRrATLh1SHlamyGV58zM%3D&reserved=0 >> >><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpl.link >>edin.com%2Fin%2Fpiotr-zarzycki-92a53552&data=02%7C01%7C%7Cab4e20a981d44a9 >>ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364222459 >>42183624&sdata=tSGDWZ5AhBPECbf1%2Fy9R2u9N4qwJ03VBhzwzNsPTcCM%3D&reserved= >>0> >> >> GitHub: >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c >>om%2Fpiotrzarzycki21&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7 >>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=lMum >>yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0 >
