royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: [Royale] Flex to FlexJS migration path
Date Tue, 03 Oct 2017 20:18:17 GMT
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