Sounds worth a try. Note that Royale ASDoc is currently a Royale app. Also note that regular Flex used [Alternative] metadata to point from MX components to Spark components. I think we want the opposite, though, and point from Royale components back to MX and Spark components.
I believe that any new asdoc tags or metadata goes in the JSON files used by the Royale ASDoc app so data should be easy to create. HTH, -Alex On 10/3/17, 1:33 PM, "Harbs" <harbs.li...@gmail.com> wrote: >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.apa >>>>>che >>>>> >>>>>.org%2F~pent%2FFlex2Royale%2F&data=02%7C01%7C%7C8a812742e9fc437f944508 >>>>>d50 >>>>> >>>>>a9b42ed%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642658431317237 >>>>>3&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%2F >>>>>>>>>pl. >>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > >
