Hi Peter, I was also thinking how to help Nicolas and other folks who came with similar problems.
I believe such table should contains Flex Component/Royale Component/Beads/Description - Flex Component - Just name Royale Component - Name/Names of the Views if there are some which doing more Beads - Possible Beads used by components Description - Maybe sub pages with longer summary I was going to start this one in the repository where Olaf put his documentation idea. But fill free start it in current Royale repo - I hope all Olaf's effort will be moved there too. If you put it nicely as an wiki - we can later make it as github page file. Olaf has following section [1] - "Migrate from Flex to FlexJs" [1] https://github.com/ok-at-github/flexjs-docs/wiki Piotr On Fri, Sep 29, 2017, 20:40 Peter Ent <p...@adobe.com> wrote: > Hi, > > I'm moving to discussion over to Royale, but still including users from > flex who have not yet subscribed to the new Royale email lists. > > I was speaking with Alex earlier and we thought the idea of a comparison > table was a good one. I've been giving some thought to what this might > look like and how complex it should (and it could) be. > > Take for example, Panel. Both Flex and Royale have a Panel. There are some > differences and, being a developer myself, I'd like at least a quick > comparison so I would know how to convert any uses of Panel such as MXML > attribute differences and such. > > Using TextInput as another example, the Royale TextInput has far few > options, but things like password security can be added as beads. > > We were also thinking of an app that would dive into the ASDocs and > present a side-by-side, where possible, comparison. That would be a bit of > a project. > > Please share your thoughts. > > Regards, > Peter Ent > Adobe Systems/Apache Royale Project > > On 9/28/17, 6:43 PM, "Idylog - Nicolas Granon" <ngra...@idylog.com> wrote: > > >Many thanks for your comments and thoughts, > > > >(this thread is a follow-up of "[FlexJS] Guidelines for implementation of > >layout containers and navigation containers" but I felt that the topic > >was getting more general). > > > >(May I remind to the readers that my company is not very interested in > >keeping a "dual output" (SWF/JS) from FlexJS. We believe that FlexJS > >should concentrate on outputting JS, and JS only, from AS3 and MXML code. > >We also believe that MXML/AS3 project directed to AIR should stay under > >the Flex umbrella (not FlexJS). It is however interesting if library > >(modules/SWC) project can have dual output, but it is not mandatory. Our > >opinions do not reflect all the use-cases of the Flex community! We will > >be happy to hear from other people and differing opinions). > > > >I have to say that it is really a pleasure to have that kind of > >discussion and that your height of view is quite amazing (I'm not sure > >that "height of view" is a correct English expression ??? Please excuse > >my bad English). > > > >We, at Idylog - and others - have obviously strong calendar constraints. > >We can expect a real decrease in Flash Player support from browser > >editors in the next 12 months, well before Adobe end of support. > > > >Add to that all the apple-fan crowd (and others) being so happy that > >Flash Player is - at last - sent to the grave (I have read such papers). > >And all the people who do not even know that Flex exists, is based on FP, > >and is used for day to day operations in hundreds (thousands ?) of > >companies but are sooo happy that FP will finally disappear.. > > > >I am pretty sure that running FP on our customers' workstations will be > >_very_ problematic well before Dec. 2020. > > > >In my company alone (and it's a tiny company!) two of my customers have > >already shown signs of nervousness. And every time there is a small > >glitch in one of our software, I immediately receive a call like "We had > >this problem because FP is over and your are keeping us in obsolete > >technology" !! No kidding. > > > >That said, I am a big fan of Flex (and FlexJS) and AS3. > >I believe that the fact that the language is *less* permissive and *less* > >flexible than JS is in fact a very good thing for the kind of software > >that we, at IdyLog, develop. > > > >But, to quote a popular series, "we are running out of time". > > > >I fully understand that you value "independence from layers of > >management". I understand that you want to give power of decision to > >everyone. It is a great and noble goal. > >And I fully support it in the domains of education, civil rights, freedom > >of thought/speech, criticism, politics, artistic creativity, academic > >research... everything intellectual and/or related to personal life but > >away from economic/profits concerns. > > > >The reality of my kind of company is : can I deliver an operational, > >functional, reliable, cheap solution in 5 weeks from scratch ? (or, as an > >architect, since we like to think about us as "digital architects" : can > >I have this house build in 12 months from scratch and under budget ? And > >we are not talking about building the next Chicago Art Museum ! Just an > >ordinary house !). That is why we cannot live without a reliable "faucet > >catalog" (and windows, and doors, and stairs and ready-to-use concrete > >formula and tiles etc.). > > > >We try to think "craftsmen" when we are in the conception phase, and > >think "industrial" when building the software (ever heard of "maintenance > >fees" from an architect ? Not me !). > > > >I would be quite happy if FlexJS could provide us with a reliable > >migration path (especially regarding UI components). > > > >As an example, it would be VERY useful to have a table showing, for each > >class from Flex SDK (that's a lot !), > >- the corresponding flexJS class if any (same API, same functionality, > >the class name might be identical or different) > >- if no corresponding class, the equivalent FlexJS class (with a detailed > >enumeration of differences between the two, plus examples, and for each > >strand, all the available beads) > >- if no equivalent, a suggested best-fit equivalent from an existing > >third-party JS library (with a short enumeration of differences) > >- if none of the above is available, a suggestion on how an equivalent > >class could be constructed (inheritance/composition clues) > >- the Flex SDK version number of the original class + link to reference > >docs > >- the FlexJS SDK version number of the target class + link to reference > >docs > > > >(I wrote "class", it obviously applies to interfaces too). > > > >For each FlexJS "equivalent" class, it should read : > >- whether the equivalent is JS only, or JS/SWF, or SWF only > > > >Such a document would be a great help in migration. > > > >Best regards, > > > >Nicolas Granon > > > > > > > > > >> -----Message d'origine----- > >> De : Alex Harui [mailto:aha...@adobe.com.INVALID] > >> Envoyé : jeudi 28 septembre 2017 22:32 > >> À : users@flex.apache.org; ngra...@idylog.com > >> Objet : Re: [FlexJS] Guidelines for implementation of layout containers > >> and navigation containers > >> > >> Hi Nicolas, > >> > >> The Application developer is not required to use composition. They are > >> most welcome to use inheritance just like in regular Flex and in fact, > >> the MXML component workflow is the same as regular Flex and based on > >> inheritance. > >> > >> You are correct about the Faucet analogy. Faucet developers are > >> Component developers in FlexJS are are encouraged to compose new > >> faucets out of different smaller pieces (choose a metal, choose a > >> handle, choose pipe size). What we don't have is a shopping catalog of > >> faucets (popular > >> components) mainly because we are too new to have any metrics about > >> popularity. If you choose FlexJS you will be one of our first > >> reviewers. > >> > >> For sure, React has much better support right now because it has the > >> money to pay people to do it. Apache projects are volunteer/community > >> driven, not corporation driven, and in our case we don't have the money > >> and need folks to pitch in. In return for pitching in, you get more > >> control. You get to have the bugs fixed you need fixed if you know how > >> to fix them, no layers of management in your way. > >> > >> HTH, > >> -Alex > >> > >> On 9/28/17, 12:43 PM, "Idylog - Nicolas Granon" <ngra...@idylog.com> > >> 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%2Fcwik > >> i > >> >>.ap > >> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d > >> a > >> >>ta= > >> >>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed > >> 2 > >> >>c17 > >> >>8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3Xruu84 > >> A > >> >>q88 > >> >>7xFTPSj2DuB%2B0%3D&reserved=0 > >> >> es+and+Layouts > >> >> [2] > >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > >> u > >> >>b.c > >> >>om%2Fapache%2Froyale- > >> asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs&data=02 > >> >>%7C > >> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178 > >> d > >> >>ece > >> >>e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR6MDc%2 > >> B > >> >>t1Y > >> >>YMHGPVL7jA%3D&reserved=0 > >> >> [3] > >> >> > >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > >> u > >> >>b.c > >> >>om%2Fapache%2Froyale- > >> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926 > >> >>88% > >> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata > >> = > >> >>xB2 > >> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0 > >> >> > >> >>asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apache/ > >> f > >> >>l > >> >> ex/html > >> >> [4] > >> >> > >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik > >> i > >> >>.ap > >> >>ache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat > >> a > >> >>=02 > >> >>%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c > >> 1 > >> >>78d > >> >>ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7a8lQTz > >> L > >> >>8KG > >> >>N7kM0uCu2z4%3D&reserved=0 > >> >> 28 > >> >> [5] > >> >> > >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > >> u > >> >>b.c > >> >>om%2Fapache%2Froyale- > >> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926 > >> >>88% > >> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata > >> = > >> >>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%2Fgith > >> u > >> >>b.c > >> >>om%2Fapache%2Froyale- > >> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926 > >> >>88% > >> >>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%2Fgetm > >> d > >> >>l.i > >> >>o%2Fcomponents%2Findex.html&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d > >> 5 > >> >>06a > >> >>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%2Fcwik > >> i > >> >>.ap > >> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data > >> = > >> >>02% > >> >>7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c1 > >> 7 > >> >>8de > >> >>cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xRtJrdXn > >> D > >> >>Lai > >> >>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%2Fcwik > >> i > >> >>.ap > >> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0 > >> 2 > >> >>%7C > >> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178 > >> d > >> >>ece > >> >>e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoLzLHc8v > >> 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%2Fwww.l > >> i > >> >>nke > >> >>din.com%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%2Fin%2Fpiotr-zarzycki- > >> 92a53552&data=02%7C01%7C%7Cab4e20a981d4 > >> >>4a9 > >> >>ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422 > >> 2 > >> >>459 > >> >>42183624&sdata=tSGDWZ5AhBPECbf1%2Fy9R2u9N4qwJ03VBhzwzNsPTcCM%3D&reser > >> v > >> >>ed= > >> >>0> > >> >> > >> >> GitHub: > >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > >> u > >> >>b.c > >> >>om%2Fpiotrzarzycki21&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926 > >> 8 > >> >>8%7 > >> >>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata= > >> l > >> >>Mum > >> >>yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0 > >> > > > > > > >
