royale-dev 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:22:06 GMT
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