flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Kessler <kesslerconsult...@gmail.com>
Subject Re: [Royale] Flex to FlexJS migration path
Date Tue, 03 Oct 2017 19:26:59 GMT
This looks good so far.  Based on the information in it, this will be
a larger page.  But it definitely adds clarity.

-Mark K

On Tue, Oct 3, 2017 at 1:30 PM, Peter Ent <pent@adobe.com.invalid> 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