Hmm. Thinking about it some more, I’m thinking that a Royale app to display the data could be a very good idea. It could solve the real estate problem and make finding options very easy.
Basically, you could either browse for search for a mx or spark component and you could then get a picker for all the component sets which have a match. As we build out our component sets there could be multiple matches or alternates. We’d have to come up with a data format for finding references to matching or alternative components. Ideally this would be info that’s pulled from the ASDoc output. Thoughts? > On Oct 3, 2017, at 11:22 PM, Harbs <harbs.li...@gmail.com> wrote: > > 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 <aha...@adobe.com> 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" <harbs.li...@gmail.com> 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 <p...@adobe.com> 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" <ngra...@idylog.com> >>>> 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:aha...@adobe.com.INVALID] >>>>>> Envoyé : samedi 30 septembre 2017 07:56 >>>>>> À : us...@royale.apache.org; users@flex.apache.org; ngra...@idylog.com >>>>>> 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 >>>>>> <piotrzarzyck...@gmail.com<mailto:piotrzarzyck...@gmail.com>> >>>>>> Reply-To: "us...@royale.apache.org<mailto:us...@royale.apache.org>" >>>>>> <us...@royale.apache.org<mailto:us...@royale.apache.org>> >>>>>> Date: Friday, September 29, 2017 at 5:00 PM >>>>>> To: "us...@royale.apache.org<mailto:us...@royale.apache.org>" >>>>>> <us...@royale.apache.org<mailto:us...@royale.apache.org>>, >>>>>> "users@flex.apache.org<mailto:users@flex.apache.org>" >>>>>> <users@flex.apache.org<mailto:users@flex.apache.org>>, >>>>>> "ngra...@idylog.com<mailto:ngra...@idylog.com>" >>>>>> <ngra...@idylog.com<mailto:ngra...@idylog.com>> >>>>>> 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 >>>>>> <aha...@adobe.com<mailto: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<mailto: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<mailto: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<mailto:aha...@adobe.com.INVALID>] >>>>>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À : >>>>>>>>> users@flex.apache.org<mailto:users@flex.apache.org>; >>>>>>>>> ngra...@idylog.com<mailto: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<mailto: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<mailto:piotrzarzyck...@gmail.co >>>>>>>>>>> m>] Envoyé : jeudi 28 septembre 2017 19:08 À : >>>>>>>>>>> users@flex.apache.org<mailto: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%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 >>>>>>>>>>> <ngra...@idylog.com<mailto: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%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 >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> >> >
