That is a great idea ! That would allow to hide/show columns and (partially) solve the real-estate issue.
It would also be a great "live example" (maybe the source code could be made public ?) Nicolas Granon > -----Message d'origine----- > De : Harbs [mailto:[email protected]] > Envoyé : mardi 3 octobre 2017 22:33 > À : [email protected] > Cc : [email protected]; [email protected] > Objet : Re: [Royale] Flex to FlexJS migration path > > 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 <[email protected]> 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 <[email protected]> wrote: > >> > >> OK, maybe wait until royale-docs is up and try GH Pages? Or if it > is > >> better as plain HTML, put it on royale.a.o? > >> > >> -Alex > >> > >> On 10/3/17, 1:13 PM, "Harbs" <[email protected]> wrote: > >> > >>> Definitely on the right path. > >>> > >>> I thought I’d try and copy this into the Github wiki, but wowsers! > >>> Tables are *hard* in Markdown, and it seems like multiline tables > >>> are hard or impossible on Github wiki pages. :-( > >>> > >>>> On Oct 3, 2017, at 8:30 PM, Peter Ent <[email protected]> wrote: > >>>> > >>>> I have a quick sample web page up at: > >>>> > >>>> > >>>> > https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fhome. > >>>> apache > >>>> > .org%2F~pent%2FFlex2Royale%2F&data=02%7C01%7C%7C8a812742e9fc437f944 > >>>> 508d50 > >>>> > a9b42ed%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642658431317 > >>>> 2373&s > >>>> data=NtSbdc6hLrusGzB5fiu%2FNsim0Xo5bNvQczCUvVmU40U%3D&reserved=0 > >>>> > >>>> I did not spend much time styling it and it is the first concept I > >>>> thought of after looking at the table below. I did not include yet > >>>> where MDL might come into play. There is a real estate issue in > >>>> getting all of this information onto the screen. > >>>> > >>>> I thought about what kind of information I would like to know when > >>>> considering to port, or actually porting, a Flex app to Royale. > Key > >>>> things for me would be data binding and what components are > >>>> available. > >>>> Combining > >>>> ActionScript/MXML is essentially the same for Royale as it is for > Flex. > >>>> > >>>> I put the stress on the Express package by making it the second > column. > >>>> In > >>>> this example I used Panel (which has no Express component yet) and > >>>> TextInput (which does have an Express version). This way people > can > >>>> see how they would convert a TextInput into a Royale TextInput and > >>>> let them choose to either use the Express version or the Basic > version. > >>>> > >>>> Give this some thought and let me know if you like the direction, > >>>> want to have other information included, do something else > >>>> entirely, etc. > >>>> > >>>> Thanks, > >>>> Peter > >>>> > >>>> On 9/30/17, 7:47 AM, "Idylog - Nicolas Granon" > <[email protected]> > >>>> wrote: > >>>> > >>>>> Hi Alex and all, > >>>>> > >>>>> In my eyes (and in my dreams !), this migration helper table > could > >>>>> be as simple as : > >>>>> > >>>>> > >>>>> +---------------------------------------------------------------- > - > >>>>> +------ > >>>>> -- > >>>>> -------------------------------------------------------------+ > >>>>> |Flex component class | Closest FlexJS equivalent > | Closest > >>>>> non-FlexJS > >>>>> equivalent (MDL...) |Implementation hints | > >>>>> > >>>>> +---------------------------------------------------------------- > - > >>>>> +------ > >>>>> -- > >>>>> -------------------------------------------------------------+ > >>>>> |mx.containers.TabNavigator | None (or empty) > | None (or > >>>>> empty) |Extends xxx Implements xxx > | > >>>>> |spark.ButtonBar | > | yyyyyy | > | > >>>>> |spark.validator.NumberValidator | yyyyyyy > | | > | > >>>>> | etc. | > | | > | > >>>>> > >>>>> +---------------------------------------------------------------- > - > >>>>> +------ > >>>>> -- > >>>>> -------------------------------------------------------------+ > >>>>> > >>>>> The "flex class" should point (link to) Flex API reference > >>>>> documentation > >>>>> > >>>>> The "closest FlexJS implementation" should link to FlexJS API > >>>>> reference documentation (or should it be "Apache Royale" ?) > >>>>> > >>>>> The "closest non-FlexJS" should in fact be "closest MDL > >>>>> equivalent" if MDL is the "official" additional UI library. We do > >>>>> not want to start opinion wars about "which is the best > equivalent > >>>>> in the world" ! It should restrict only to one or two "official" > >>>>> (meaning > >>>>> FlexJS-recommended) libraries and not try to explore all > available > >>>>> libraries. > >>>>> > >>>>> Implementation hints would be useful when there is really no > close > >>>>> equivalent and give clues to developers as where to start in > order > >>>>> to build a close equivalent. > >>>>> Or maybe "implementation hints" could link to some kind of wiki > >>>>> where contributors could discuss and express their opinions as > >>>>> there are usually several approaches. > >>>>> > >>>>> It would be better if there is some filter on flex package (or > >>>>> sub-package) and a search function also. > >>>>> Maybe it would be useful if there is a filter for showing only > >>>>> Flex component who have a FlexJS equivalent (excluding MDL > >>>>> equivalent, and no equivalent at all) and also an "inverse" > filter > >>>>> (Flex component having only a MDL counterpart for those who want > >>>>> to stick to MDL). > >>>>> > >>>>> Basic ordering should be by package (like in the Flex reference > docs). > >>>>> > >>>>> If there is a FlexJS implementation, it is not necessary to give > a > >>>>> MDL implementation (?). > >>>>> If there is a FlexJS or a MDL implementation, implementation > hints > >>>>> should be empty (?). > >>>>> > >>>>> I think this leads naturally to giving the "express" > >>>>> implementation as "closest FlexJS equivalent" because it would > >>>>> usually really be the "closest equivalent". > >>>>> The link to API reference documentation would allow to see how > the > >>>>> "express" version is constructed and all the implementation > >>>>> details and examples (something very close to Flex API reference > >>>>> docs where interfaces and ancestors are readily readable). > >>>>> > >>>>> If closest equivalent is MDL, it might be difficult to have a > link > >>>>> to specific doc page (since it is outside Flex and FlexJS docs, > >>>>> and could change without notice). May be a global MDL docs entry > >>>>> link in the side bar is the best option... > >>>>> > >>>>> Maybe a "discussion" link (on each line) would be interesting : > it > >>>>> could lead to a page where implementers and developers could > share > >>>>> their experience on a component-by-component basis, share their > >>>>> customization tips etc. > >>>>> I'm not sure if this is different from "implementation hints"... > >>>>> In my mind "implementation hints" is really about components who > >>>>> do not really have an equivalent. "Discussion" is more about > >>>>> usage/customization experience or existing equivalents. > >>>>> > >>>>> Maybe the "closest implementation" columns could be merged and an > >>>>> icon would indicate if this closest implementation sits in the > >>>>> FlexJS/Royale world or the MDL world. > >>>>> (is "Apache Royale" the new designation of "FlexJS" ? And should > I > >>>>> drop entirely "FlexJS" from my posts ?) > >>>>> > >>>>> The "Flex" column could (should) be directly constructed from > >>>>> existing Flex reference docs. > >>>>> > >>>>> It would also be very useful for non-UI classes (XML, > >>>>> FileReference, Formatters,Remoting etc...), showing possible > >>>>> "holes" in JS implementation. > >>>>> > >>>>> It probably should link to Flex Apache docs... it is more logical > >>>>> since they contains at least the same information as Adobe docs > >>>>> and they are supposed to be more up-to-date than Adobe docs. > >>>>> > >>>>> Maybe, for classes who *cannot* have an equivalent class (for > >>>>> conceptual reasons), the link (in "Implementation hints") should > >>>>> explain why, in the JS/HTML world, an implementation is > >>>>> useless/meaningless. > >>>>> > >>>>> Of course, there are situations where it is not really possible > to > >>>>> map components one-to-one (maybe, for example, because two > >>>>> distinct Flex components are composited in only one MDL > >>>>> component). This should not be a big deal with the help of one or > >>>>> two lines of comments. > >>>>> > >>>>> Hope this helps, > >>>>> > >>>>> Regards, > >>>>> > >>>>> Nicolas Granon > >>>>> > >>>>> > >>>>> > >>>>>> -----Message d'origine----- > >>>>>> De : Alex Harui [mailto:[email protected]] Envoyé : > samedi > >>>>>> 30 septembre 2017 07:56 À : [email protected]; > >>>>>> [email protected]; [email protected] Objet : Re: [Royale] > >>>>>> Flex to FlexJS migration path > >>>>>> > >>>>>> It wouldn't be a bad idea for more than one person to try to > >>>>>> present this comparison. Then we can see which presentation(s) > >>>>>> are useful and iterate towards a final solution or solutions. > >>>>>> > >>>>>> My personal philosophy is to try to not disappoint, so having > >>>>>> Basic in a list and finding out later it requires a lot of > >>>>>> configuration or doesn't have some important APIs may not be as > >>>>>> good an approach as just comparing Express, which should compare > >>>>>> more favorably. > >>>>>> > >>>>>> My 2 cents, > >>>>>> -Alex > >>>>>> > >>>>>> From: Piotr Zarzycki > >>>>>> <[email protected]<mailto:[email protected]>> > >>>>>> Reply-To: > "[email protected]<mailto:[email protected]>" > >>>>>> <[email protected]<mailto:[email protected]>> > >>>>>> Date: Friday, September 29, 2017 at 5:00 PM > >>>>>> To: "[email protected]<mailto:[email protected]>" > >>>>>> <[email protected]<mailto:[email protected]>>, > >>>>>> "[email protected]<mailto:[email protected]>" > >>>>>> <[email protected]<mailto:[email protected]>>, > >>>>>> "[email protected]<mailto:[email protected]>" > >>>>>> <[email protected]<mailto:[email protected]>> > >>>>>> Subject: Re: [Royale] Flex to FlexJS migration path > >>>>>> > >>>>>> > >>>>>> Hmm..But I was in my mind something simple. If we just show the > >>>>>> names > >>>>>> - > >>>>>> without to much details - even Basic can landed onto that table. > >>>>>> Once user see names will be able to look himself into that. > >>>>>> > >>>>>> Piotr > >>>>>> > >>>>>> On Sat, Sep 30, 2017, 00:22 Alex Harui > >>>>>> <[email protected]<mailto:[email protected]>> wrote: > >>>>>> IMO, we want to compare the Express and maybe MDL packages > >>>>>> against Flex's Spark and MX. Comparing Basic components will be > >>>>>> too difficult because of how configurable they are. And this > >>>>>> might inspire us to create a Migration component set that is > >>>>>> better tuned to ease migration. > >>>>>> > >>>>>> My 2 cents, > >>>>>> -Alex > >>>>>> > >>>>>> On 9/29/17, 11:40 AM, "Peter Ent" > >>>>>> <[email protected]<mailto:[email protected]>> wrote: > >>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> I'm moving to discussion over to Royale, but still including > >>>>>>> users > >>>>>> from > >>>>>>> flex who have not yet subscribed to the new Royale email lists. > >>>>>>> > >>>>>>> I was speaking with Alex earlier and we thought the idea of a > >>>>>>> comparison table was a good one. I've been giving some thought > >>>>>>> to what this might look like and how complex it should (and it > >>>>>>> could) be. > >>>>>>> > >>>>>>> Take for example, Panel. Both Flex and Royale have a Panel. > >>>>>>> There are some differences and, being a developer myself, I'd > >>>>>>> like at least a quick comparison so I would know how to convert > >>>>>>> any uses of Panel such as MXML attribute differences and such. > >>>>>>> > >>>>>>> Using TextInput as another example, the Royale TextInput has > far > >>>>>>> few options, but things like password security can be added as > beads. > >>>>>>> > >>>>>>> We were also thinking of an app that would dive into the ASDocs > >>>>>>> and present a side-by-side, where possible, comparison. That > >>>>>>> would be a > >>>>>> bit > >>>>>>> of a project. > >>>>>>> > >>>>>>> Please share your thoughts. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Peter Ent > >>>>>>> Adobe Systems/Apache Royale Project > >>>>>>> > >>>>>>> On 9/28/17, 6:43 PM, "Idylog - Nicolas Granon" > >>>>>> <[email protected]<mailto:[email protected]>> wrote: > >>>>>>> > >>>>>>>> Many thanks for your comments and thoughts, > >>>>>>>> > >>>>>>>> (this thread is a follow-up of "[FlexJS] Guidelines for > >>>>>> implementation > >>>>>>>> of layout containers and navigation containers" but I felt > that > >>>>>>>> the topic was getting more general). > >>>>>>>> > >>>>>>>> (May I remind to the readers that my company is not very > >>>>>>>> interested > >>>>>> in > >>>>>>>> keeping a "dual output" (SWF/JS) from FlexJS. We believe that > >>>>>>>> FlexJS should concentrate on outputting JS, and JS only, from > >>>>>>>> AS3 and MXML > >>>>>> code. > >>>>>>>> We also believe that MXML/AS3 project directed to AIR should > >>>>>>>> stay under the Flex umbrella (not FlexJS). It is however > >>>>>>>> interesting if library > >>>>>>>> (modules/SWC) project can have dual output, but it is not > mandatory. > >>>>>>>> Our opinions do not reflect all the use-cases of the Flex > community! > >>>>>>>> We will be happy to hear from other people and differing > opinions). > >>>>>>>> > >>>>>>>> I have to say that it is really a pleasure to have that kind > of > >>>>>>>> discussion and that your height of view is quite amazing (I'm > >>>>>>>> not > >>>>>> sure > >>>>>>>> that "height of view" is a correct English expression ??? > >>>>>>>> Please excuse my bad English). > >>>>>>>> > >>>>>>>> We, at Idylog - and others - have obviously strong calendar > >>>>>> constraints. > >>>>>>>> We can expect a real decrease in Flash Player support from > >>>>>>>> browser editors in the next 12 months, well before Adobe end > of support. > >>>>>>>> > >>>>>>>> Add to that all the apple-fan crowd (and others) being so > happy > >>>>>>>> that Flash Player is - at last - sent to the grave (I have > read > >>>>>>>> such > >>>>>> papers). > >>>>>>>> And all the people who do not even know that Flex exists, is > >>>>>>>> based on FP, and is used for day to day operations in hundreds > >>>>>>>> (thousands ?) > >>>>>> of > >>>>>>>> companies but are sooo happy that FP will finally disappear.. > >>>>>>>> > >>>>>>>> I am pretty sure that running FP on our customers' > workstations > >>>>>>>> will be _very_ problematic well before Dec. 2020. > >>>>>>>> > >>>>>>>> In my company alone (and it's a tiny company!) two of my > >>>>>>>> customers have already shown signs of nervousness. And every > >>>>>>>> time there is a small glitch in one of our software, I > >>>>>>>> immediately receive a call > >>>>>> like > >>>>>>>> "We had this problem because FP is over and your are keeping > us > >>>>>>>> in obsolete technology" !! No kidding. > >>>>>>>> > >>>>>>>> That said, I am a big fan of Flex (and FlexJS) and AS3. > >>>>>>>> I believe that the fact that the language is *less* permissive > >>>>>>>> and > >>>>>>>> *less* flexible than JS is in fact a very good thing for the > >>>>>>>> kind of software that we, at IdyLog, develop. > >>>>>>>> > >>>>>>>> But, to quote a popular series, "we are running out of time". > >>>>>>>> > >>>>>>>> I fully understand that you value "independence from layers of > >>>>>>>> management". I understand that you want to give power of > >>>>>>>> decision to everyone. It is a great and noble goal. > >>>>>>>> And I fully support it in the domains of education, civil > >>>>>>>> rights, freedom of thought/speech, criticism, politics, > >>>>>>>> artistic creativity, academic research... everything > >>>>>>>> intellectual and/or related to personal life but away from > economic/profits concerns. > >>>>>>>> > >>>>>>>> The reality of my kind of company is : can I deliver an > >>>>>>>> operational, functional, reliable, cheap solution in 5 weeks > >>>>>>>> from scratch ? (or, > >>>>>> as > >>>>>>>> an architect, since we like to think about us as "digital > >>>>>>>> architects" > >>>>>>>> : can I have this house build in 12 months from scratch and > >>>>>>>> under budget ? And we are not talking about building the next > >>>>>>>> Chicago Art Museum ! Just an ordinary house !). That is why we > >>>>>>>> cannot live > >>>>>> without > >>>>>>>> a reliable "faucet catalog" (and windows, and doors, and > stairs > >>>>>>>> and ready-to-use concrete formula and tiles etc.). > >>>>>>>> > >>>>>>>> We try to think "craftsmen" when we are in the conception > >>>>>>>> phase, and think "industrial" when building the software (ever > >>>>>>>> heard of "maintenance fees" from an architect ? Not me !). > >>>>>>>> > >>>>>>>> I would be quite happy if FlexJS could provide us with a > >>>>>>>> reliable migration path (especially regarding UI components). > >>>>>>>> > >>>>>>>> As an example, it would be VERY useful to have a table > showing, > >>>>>>>> for each class from Flex SDK (that's a lot !), > >>>>>>>> - the corresponding flexJS class if any (same API, same > >>>>>> functionality, > >>>>>>>> the class name might be identical or different) > >>>>>>>> - if no corresponding class, the equivalent FlexJS class (with > >>>>>>>> a detailed enumeration of differences between the two, plus > >>>>>>>> examples, and for each strand, all the available beads) > >>>>>>>> - if no equivalent, a suggested best-fit equivalent from an > >>>>>>>> existing third-party JS library (with a short enumeration of > >>>>>>>> differences) > >>>>>>>> - if none of the above is available, a suggestion on how an > >>>>>> equivalent > >>>>>>>> class could be constructed (inheritance/composition clues) > >>>>>>>> - the Flex SDK version number of the original class + link to > >>>>>>>> reference docs > >>>>>>>> - the FlexJS SDK version number of the target class + link to > >>>>>>>> reference docs > >>>>>>>> > >>>>>>>> (I wrote "class", it obviously applies to interfaces too). > >>>>>>>> > >>>>>>>> For each FlexJS "equivalent" class, it should read : > >>>>>>>> - whether the equivalent is JS only, or JS/SWF, or SWF only > >>>>>>>> > >>>>>>>> Such a document would be a great help in migration. > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> > >>>>>>>> Nicolas Granon > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Message d'origine----- > >>>>>>>>> De : Alex Harui > >>>>>>>>> > [mailto:[email protected]<mailto:[email protected] > >>>>>>>>> ID>] Envoyé : jeudi 28 septembre 2017 22:32 À : > >>>>>>>>> [email protected]<mailto:[email protected]>; > >>>>>>>>> [email protected]<mailto:[email protected]> > >>>>>>>>> Objet : Re: [FlexJS] Guidelines for implementation of layout > >>>>>>>>> containers and navigation containers > >>>>>>>>> > >>>>>>>>> Hi Nicolas, > >>>>>>>>> > >>>>>>>>> The Application developer is not required to use composition. > >>>>>>>>> They are most welcome to use inheritance just like in regular > >>>>>>>>> Flex and > >>>>>> in > >>>>>>>>> fact, the MXML component workflow is the same as regular Flex > >>>>>>>>> and based on inheritance. > >>>>>>>>> > >>>>>>>>> You are correct about the Faucet analogy. Faucet developers > >>>>>>>>> are Component developers in FlexJS are are encouraged to > >>>>>>>>> compose new faucets out of different smaller pieces (choose a > >>>>>>>>> metal, choose a handle, choose pipe size). What we don't > have > >>>>>>>>> is a shopping > >>>>>> catalog > >>>>>>>>> of faucets (popular > >>>>>>>>> components) mainly because we are too new to have any metrics > >>>>>>>>> about popularity. If you choose FlexJS you will be one of > our > >>>>>>>>> first reviewers. > >>>>>>>>> > >>>>>>>>> For sure, React has much better support right now because it > >>>>>>>>> has > >>>>>> the > >>>>>>>>> money to pay people to do it. Apache projects are > >>>>>>>>> volunteer/community driven, not corporation driven, and in > our > >>>>>>>>> case we don't have the money and need folks to pitch in. In > >>>>>>>>> return for pitching in, you get more control. You get to > have > >>>>>>>>> the bugs fixed you need fixed if you know how to fix them, no > >>>>>>>>> layers of management > >>>>>> in your way. > >>>>>>>>> > >>>>>>>>> HTH, > >>>>>>>>> -Alex > >>>>>>>>> > >>>>>>>>> On 9/28/17, 12:43 PM, "Idylog - Nicolas Granon" > >>>>>>>>> <[email protected]<mailto:[email protected]>> > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> Hi Piotr, > >>>>>>>>>> > >>>>>>>>>> Many thanks for your help. > >>>>>>>>>> > >>>>>>>>>> We are not interested *at all* in SWF compatibility or > >>>>>>>>>> alignment between a SWF and a JS version. > >>>>>>>>>> Our goal is to migrate our browser-based applications > catalog > >>>>>>>>>> out of Flash player. We will keep AIR apps (desktop/mobile) > >>>>>>>>>> under the > >>>>>>>>> Flex/AIR > >>>>>>>>>> hood. Common libraries (which usually do not have any UI) > >>>>>>>>>> will be upgraded to mixed-mode when necessary (and if > >>>>>>>>>> possible ! If not possible > >>>>>>>>>> - or too complicated - we will have two versions, of for > SWF, > >>>>>>>>>> and one for JS). > >>>>>>>>>> > >>>>>>>>>> So maybe our best bet is to work on the integration of > >>>>>>>>>> existing > >>>>>> JS- > >>>>>>>>> only > >>>>>>>>>> UI components... (MDL, jQuery etc.) > >>>>>>>>>> > >>>>>>>>>> It would be nice if we had some clues about which JS UI > >>>>>>>>>> library > >>>>>> (or > >>>>>>>>>> libraries) would be the closest to Flex-SWF components in > >>>>>>>>>> terms of functionalities. > >>>>>>>>>> > >>>>>>>>>> (we would not like to have to pick from half a dozen > >>>>>>>>>> different libraries ! We like things simple and powerful !). > >>>>>>>>>> > >>>>>>>>>> We found Sensha UI libraries very nice, but wayyyy too > >>>>>>>>>> expensive (but we do not mind paying a reasonable license > price). > >>>>>>>>>> > >>>>>>>>>> We develop only enterprise management software (no games, no > >>>>>>>>> "personal" > >>>>>>>>>> utilities) and the components that we use the most are > >>>>>>>>>> Datagrid, HierarchicalDatagrid (very important), Forms > >>>>>>>>>> (FormItem etc.), Validators (and custom validators), > >>>>>>>>>> DropdownList... I will not enumerate all of them but you > >>>>>>>>>> understand our needs... Localization is also very important > >>>>>>>>>> to us > >>>>>>>>>> (ResourceManager) and also quick and flexible layout > >>>>>>>>>> management (but > >>>>>>>>> we > >>>>>>>>>> never use "custom" layouts). > >>>>>>>>>> On the other hand, visual skinning is not the most important > >>>>>> thing. > >>>>>>>>>> In our world, the most important thing is reliability, > >>>>>> performance, > >>>>>>>>>> and ease of use. Cosmetics comes at the bottom of our > >>>>>>>>>> wishlist (even if it is somehow related to ease of use). > >>>>>>>>>> > >>>>>>>>>> Another problem we face (for custom components) is dealing > >>>>>>>>>> with composition vs inheritance. > >>>>>>>>>> The concept is *intellectually* cleaner. No doubt about > this. > >>>>>>>>>> But for the conceptors/implementors, what was initially very > >>>>>> simple > >>>>>>>>>> (find the closest existing component, extend it, override > >>>>>>>>>> what you > >>>>>>>>> need > >>>>>>>>>> to, add missing parts) suddenly becomes very very > complicated > >>>>>>>>>> because you have to guess what are the existing parts you > >>>>>>>>>> should assemble > >>>>>>>>>> (compose) among the hundreds of existing parts...(some of > >>>>>>>>>> them already composed...!). In the "classic" Flex world, > >>>>>>>>>> component compositing was used for...composed components ! > >>>>>>>>>> (components with multiple functional > >>>>>>>>>> "areas") Not for standalone components. > >>>>>>>>>> We feel like a contractor building a house, who needs to > >>>>>>>>>> install and tweak a faucet, and instead of having to choose > >>>>>>>>>> between four "kind" of faucets we suddenly have to imagine > >>>>>>>>>> and assemble a never-seen-before faucet by choosing between > >>>>>>>>>> all possible kinds of pipes, all possible kinds of rubber, > >>>>>>>>>> all possible kinds of metal, all possible kinds of knobs... > >>>>>>>>>> > >>>>>>>>>> I would like to say that our job is not to *build* tools but > >>>>>>>>>> to > >>>>>>>>>> *choose* tools in order to build usable software solutions. > >>>>>>>>>> We are "house contractors", not "faucet contractors". We > need > >>>>>>>>>> a "faucet catalog" (UI > >>>>>>>>>> library) with well defined characteristics. If necessary, we > >>>>>>>>>> can slightly tweak it (custom item renderer is the most > common need). > >>>>>>>>>> > >>>>>>>>>> Meanwhile, we are also testing ReactJS (although not a real > >>>>>>>>>> framework but, again, our main issue is the UI part) and I > >>>>>>>>>> must > >>>>>> say > >>>>>>>>>> that documentation, samples, contribution and community > >>>>>>>>>> activity > >>>>>> is > >>>>>>>>>> very impressive...(not event talking about robustness and > >>>>>>>>>> performance). At some point, rewriting our business logic in > >>>>>>>>>> TypeScript (yes, we are testing with TypeScript because we > >>>>>>>>>> want to stick to strongly typed code, classes...etc... and > it > >>>>>>>>>> works surprisingly well) might prove > >>>>>>>>> more > >>>>>>>>>> reliable, and not necessary more expensive... I personally > >>>>>>>>>> prefers > >>>>>>>>>> AS3 over TypeScript (easier to read, no "fancy" syntax, > >>>>>>>>>> cleaner handling > >>>>>>>>> of > >>>>>>>>>> "this"...) but TS is not bad at all. > >>>>>>>>>> > >>>>>>>>>> But we are going on in our tests and give a try to MDL (or > >>>>>> another) > >>>>>>>>>> + flexJS. > >>>>>>>>>> > >>>>>>>>>> Best regards, > >>>>>>>>>> > >>>>>>>>>> Nicolas Granon > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -----Message d'origine----- > >>>>>>>>>>> De : Piotr Zarzycki > >>>>>>>>>>> > >>>>>> > [mailto:[email protected]<mailto:[email protected] > >>>>>>>>>>> m>] Envoyé : jeudi 28 septembre 2017 19:08 À : > >>>>>>>>>>> [email protected]<mailto:[email protected]> > >>>>>>>>>>> Objet : Re: [FlexJS] Guidelines for implementation of > layout > >>>>>>>>>>> containers and navigation containers > >>>>>>>>>>> > >>>>>>>>>>> Hi Nicolas, > >>>>>>>>>>> > >>>>>>>>>>> I believe my answer will only partially satisfy you. About > >>>>>>>>> containers > >>>>>>>>>>> exists in FlexJS (Royale) you can read more here [1]. I > >>>>>>>>>>> would strongly suggest look first on our examples [2]. We > do > >>>>>>>>>>> not have ViewStack container, so I believe that is > something > >>>>>>>>>>> which can be implemented and maybe pushed to our > repository. > >>>>>>>>>>> We definitely suffer for a lack of documentation, when I > was > >>>>>>>>>>> started to dig into the framework I simply look into how > >>>>>>>>>>> actually each > >>>>>> component > >>>>>>>>>>> is implemented [3] - architecture is pretty clean in my > >>>>>>>>>>> opinion and > >>>>>>>>> more > >>>>>>>>>>> composition oriented than inheritance. Quite helpful can be > >>>>>>>>>>> this website [4] - That is the slight description about our > >>>>>>>>>>> main > >>>>>>>>> principle PAYG. > >>>>>>>>>>> > >>>>>>>>>>> As for the components itself there are module Basic [3] > >>>>>>>>>>> which contains our native components which should look same > >>>>>>>>>>> in SWF and JS, but as you probably know it is not fully > true > >>>>>>>>>>> and not necessary > >>>>>>>>> should be. > >>>>>>>>>>> > >>>>>>>>>>> There is also module MDL [5][6][7][8] which is wrapper > >>>>>>>>>>> around existing components + some implementation of some > >>>>>>>>>>> additional things like "dataProvider" in List. Encourage > you > >>>>>>>>>>> to look into the code of components as I suggested it for > >>>>>>>>>>> Basic. This module do not have SWF representation - it is > >>>>>>>>>>> simply compile to JS > >>>>>> only. > >>>>>>>>>>> > >>>>>>>>>>> I hope we will be better and better with documentation and > >>>>>>>>>>> some day new users will not have to dig into the code. I > can > >>>>>>>>>>> say also from my experience that once you will figure out > >>>>>>>>>>> how everything is working productivity is quite good. > >>>>>>>>>>> > >>>>>>>>>>> [1] > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F% > >>>>>>>> 2Fc > >>>>>>>>>>> wik > >>>>>>>>> i > >>>>>>>>>>> .ap > >>>>>>>>> > >>>>>>>> > ache.org<https://na01.safelinks.protection.outlook.com/?url=htt > >>>>>>>> p%3 > >>>>>>>>> > >>>>>>>> > A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964 > >>>>>>>> 788 > >>>>>>>>> > >>>>>>>> > %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642326439203225 > >>>>>>>> 6&s > >>>>>>>>> > >>>>>>>> > data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved= > >>>>>>>> 0>% > >>>>>>>>>>> > 2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d > >>>>>>>>> a > >>>>>>>>>>> ta= > >>>>>>>>> > >>>>>>>> > 02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438 > >>>>>>>> 794 > >>>>>>>>>>> aed > >>>>>>>>> 2 > >>>>>>>>>>> c17 > >>>>>>>>> > >>>>>>>> > 8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3 > >>>>>>>> Xru > >>>>>>>>>>> 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%7Cfa7b1b5a7b34438794ae > >>>>>>>> d2c > >>>>>>>>>>> 178 > >>>>>>>>> d > >>>>>>>>>>> ece > >>>>>>>>> > >>>>>>>> > e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR > >>>>>>>> 6MD > >>>>>>>>>>> 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/a > >>>>>>>> pac > >>>>>>>>>>> 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=htt > >>>>>>>> p%3 > >>>>>>>>> > >>>>>>>> > A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964 > >>>>>>>> 788 > >>>>>>>>> > >>>>>>>> > %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642326439203225 > >>>>>>>> 6&s > >>>>>>>>> > >>>>>>>> > data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved= > >>>>>>>> 0>% > >>>>>>>>>>> > 2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat > >>>>>>>>> a > >>>>>>>>>>> =02 > >>>>>>>>> > >>>>>>>> > %7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b3443879 > >>>>>>>> 4ae > >>>>>>>>>>> d2c > >>>>>>>>> 1 > >>>>>>>>>>> 78d > >>>>>>>>> > >>>>>>>> > ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7 > >>>>>>>> a8l > >>>>>>>>>>> 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/ma > >>>>>>>> in/ > >>>>>>>>>>> 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%7Cab4e20a981d44a9ea > >>>>>>>> 014 > >>>>>>>>>>> 08d > >>>>>>>>> 5 > >>>>>>>>>>> 06a > >>>>>>>>> > >>>>>>>> > 92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942 > >>>>>>>> 183 > >>>>>>>>>>> 624 > >>>>>>>>> & > >>>>>>>>>>> sda > >>>>>>>>> > >>>>>>>> > ta=U6IQ%2Fikcn61Row6PjP%2FLF%2F4kqle2pe4U%2BEgAuxMfL90%3D&reser > >>>>>>>> ved > >>>>>>>>>>> =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=htt > >>>>>>>> p%3 > >>>>>>>>> > >>>>>>>> > A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964 > >>>>>>>> 788 > >>>>>>>>> > >>>>>>>> > %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642326439203225 > >>>>>>>> 6&s > >>>>>>>>> > >>>>>>>> > data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved= > >>>>>>>> 0>% > >>>>>>>>>>> > 2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data > >>>>>>>>> = > >>>>>>>>>>> 02% > >>>>>>>>> > >>>>>>>> > 7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794 > >>>>>>>> aed > >>>>>>>>>>> 2c1 > >>>>>>>>> 7 > >>>>>>>>>>> 8de > >>>>>>>>> > >>>>>>>> > cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xR > >>>>>>>> tJr > >>>>>>>>>>> dXn > >>>>>>>>> D > >>>>>>>>>>> Lai > >>>>>>>>>>> 3UM8LpiO7APc%3D&reserved=0 > >>>>>>>>>>> > >>>>>>>>>>> Thanks, Piotr > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> 2017-09-28 17:58 GMT+02:00 Idylog - Nicolas Granon > >>>>>>>>>>> <[email protected]<mailto:[email protected]>>: > >>>>>>>>>>> > >>>>>>>>>>>> We need to « re-implement » a ViewStack container > component > >>>>>>>>>>>> class for use in a FlexJS (test) project. > >>>>>>>>>>>> > >>>>>>>>>>>> Is there a general walkthrough explaining (in details) the > >>>>>>>>>>>> principles when creating a container component for FlexJS > >>>>>>>>>>>> (we are mostly interested in the js output, not SWF). > >>>>>>>>>>>> > >>>>>>>>>>>> We have read the docs at > >>>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F% > >>>>>>>> 2Fc > >>>>>>>>>>> wik > >>>>>>>>> i > >>>>>>>>>>> .ap > >>>>>>>>> > >>>>>>>> > ache.org<https://na01.safelinks.protection.outlook.com/?url=htt > >>>>>>>> p%3 > >>>>>>>>> > >>>>>>>> > A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964 > >>>>>>>> 788 > >>>>>>>>> > >>>>>>>> > %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642326439203225 > >>>>>>>> 6&s > >>>>>>>>> > >>>>>>>> > data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved= > >>>>>>>> 0>% > >>>>>>>>>>> > 2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0 > >>>>>>>>> 2 > >>>>>>>>>>> %7C > >>>>>>>>> > >>>>>>>> > 01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794ae > >>>>>>>> d2c > >>>>>>>>>>> 178 > >>>>>>>>> d > >>>>>>>>>>> ece > >>>>>>>>> > >>>>>>>> > e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoL > >>>>>>>> zLH > >>>>>>>>>>> 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%2 > >>>>>>>> Fww > >>>>>>>>>>> w.l > >>>>>>>>> i > >>>>>>>>>>> nke > >>>>>>>>> > >>>>>>>> > din.com<https://na01.safelinks.protection.outlook.com/?url=http > >>>>>>>> %3A > >>>>>>>>> > >>>>>>>> > %2F%2Fdin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796478 > >>>>>>>> 8%7 > >>>>>>>>> > >>>>>>>> > Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256& > >>>>>>>> sda > >>>>>>>>> > >>>>>>>> > ta=B7M%2BhYPAUN%2FwIEe4DoMPpIjTZhxpwoTlKNrD%2FZaqkAg%3D&reserve > >>>>>>>> d=0 > >>>>>>>>>>>> > %2Fpiotrzarzycki&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d5 > >>>>>>>>>>>> 06a > >>>>>>>>> 9 > >>>>>>>>>>> 268 > >>>>>>>>> > >>>>>>>> > 8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364222459421836 > >>>>>>>> 24& > >>>>>>>>>>> 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=htt > >>>>>>>> p%3 > >>>>>>>>> > >>>>>>>> > A%2F%2Fedin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964 > >>>>>>>> 788 > >>>>>>>>> > >>>>>>>> > %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642326439203225 > >>>>>>>> 6&s > >>>>>>>>> > >>>>>>>> > data=7rUvU4thZJ3Ja1S4aMg4RwxKGwoMgN4%2FIZ4RY9W4MwE%3D&reserved= > >>>>>>>> 0>% > >>>>>>>>>>> 2Fin%2Fpiotr-zarzycki- > >>>>>>>>> 92a53552&data=02%7C01%7C%7Cab4e20a981d4 > >>>>>>>>>>> 4a9 > >>>>>>>>> > >>>>>>>> > ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C > >>>>>>>> 636 > >>>>>>>>>>> 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%7Cab4e20a981d44a9ea01408d5 > >>>>>>>> 06a > >>>>>>>>>>> 926 > >>>>>>>>> 8 > >>>>>>>>>>> 8%7 > >>>>>>>>> > >>>>>>>> > Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624& > >>>>>>>> sda > >>>>>>>>>>> ta= > >>>>>>>>> l > >>>>>>>>>>> Mum > >>>>>>>>>>> yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0 > >>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>> > >>> > >> > > >
