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:13:39 GMT
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:
> 
> http://home.apache.org/~pent/Flex2Royale/
> 
> 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