flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: [Royale] Flex to FlexJS migration path
Date Tue, 03 Oct 2017 20:33:24 GMT
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.lists@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 <aharui@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.lists@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 <pent@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" <ngranon@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:aharui@adobe.com.INVALID]
>>>>>> Envoyé : samedi 30 septembre 2017 07:56
>>>>>> À : users@royale.apache.org; users@flex.apache.org; ngranon@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
>>>>>> <piotrzarzycki21@gmail.com<mailto:piotrzarzycki21@gmail.com>>
>>>>>> Reply-To: "users@royale.apache.org<mailto:users@royale.apache.org>"
>>>>>> <users@royale.apache.org<mailto:users@royale.apache.org>>
>>>>>> Date: Friday, September 29, 2017 at 5:00 PM
>>>>>> To: "users@royale.apache.org<mailto:users@royale.apache.org>"
>>>>>> <users@royale.apache.org<mailto:users@royale.apache.org>>,
>>>>>> "users@flex.apache.org<mailto:users@flex.apache.org>"
>>>>>> <users@flex.apache.org<mailto:users@flex.apache.org>>,
>>>>>> "ngranon@idylog.com<mailto:ngranon@idylog.com>"
>>>>>> <ngranon@idylog.com<mailto:ngranon@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
>>>>>> <aharui@adobe.com<mailto:aharui@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"
>>>>>> <pent@adobe.com<mailto:pent@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"
>>>>>> <ngranon@idylog.com<mailto:ngranon@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:aharui@adobe.com.INVALID<mailto:aharui@adobe.com.INVALID>]
>>>>>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>>>>>>>>> users@flex.apache.org<mailto:users@flex.apache.org>;
>>>>>>>>> ngranon@idylog.com<mailto:ngranon@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"
>>>>>>>>> <ngranon@idylog.com<mailto:ngranon@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:piotrzarzycki21@gmail.com<mailto:piotrzarzycki21@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
>>>>>>>>>>> <ngranon@idylog.com<mailto:ngranon@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
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 



Mime
View raw message