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 <aha...@adobe.com> 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" <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 > >>> > > >> > >> > > > >
