You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@royale.apache.org by Peter Ent <pe...@adobe.com> on 2017/09/29 18:40:07 UTC
[Royale] Flex to FlexJS migration path
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" <ng...@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]
>> Envoyé : jeudi 28 septembre 2017 22:32
>> À : users@flex.apache.org; 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" <ng...@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]
>> >> Envoyé : jeudi 28 septembre 2017 19:08 À : 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%2Fcwik
>> i
>> >>.ap
>> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d
>> a
>> >>ta=
>> >>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed
>> 2
>> >>c17
>> >>8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3Xruu84
>> A
>> >>q88
>> >>7xFTPSj2DuB%2B0%3D&reserved=0
>> >> es+and+Layouts
>> >> [2]
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>> u
>> >>b.c
>> >>om%2Fapache%2Froyale-
>> asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs&data=02
>> >>%7C
>> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
>> d
>> >>ece
>> >>e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR6MDc%2
>> B
>> >>t1Y
>> >>YMHGPVL7jA%3D&reserved=0
>> >> [3]
>> >>
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>> u
>> >>b.c
>> >>om%2Fapache%2Froyale-
>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>> >>88%
>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
>> =
>> >>xB2
>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>> >>
>> >>asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apache/
>> f
>> >>l
>> >> ex/html
>> >> [4]
>> >>
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
>> i
>> >>.ap
>> >>ache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat
>> a
>> >>=02
>> >>%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c
>> 1
>> >>78d
>> >>ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7a8lQTz
>> L
>> >>8KG
>> >>N7kM0uCu2z4%3D&reserved=0
>> >> 28
>> >> [5]
>> >>
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>> u
>> >>b.c
>> >>om%2Fapache%2Froyale-
>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>> >>88%
>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
>> =
>> >>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%2Fgith
>> u
>> >>b.c
>> >>om%2Fapache%2Froyale-
>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>> >>88%
>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
>> =
>> >>xB2
>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>> >> asjs/tree/develop/examples/flexjs/MDLExample
>> >> [7]
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgetm
>> d
>> >>l.i
>> >>o%2Fcomponents%2Findex.html&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d
>> 5
>> >>06a
>> >>92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624
>> &
>> >>sda
>> >>ta=U6IQ%2Fikcn61Row6PjP%2FLF%2F4kqle2pe4U%2BEgAuxMfL90%3D&reserved=0
>> >> [8]
>> >>
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
>> i
>> >>.ap
>> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data
>> =
>> >>02%
>> >>7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c1
>> 7
>> >>8de
>> >>cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xRtJrdXn
>> D
>> >>Lai
>> >>3UM8LpiO7APc%3D&reserved=0
>> >>
>> >> Thanks, Piotr
>> >>
>> >>
>> >> 2017-09-28 17:58 GMT+02:00 Idylog - Nicolas Granon
>> >> <ng...@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%2Fcwik
>> i
>> >>.ap
>> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0
>> 2
>> >>%7C
>> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
>> d
>> >>ece
>> >>e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoLzLHc8v
>> 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%2Fwww.l
>> i
>> >>nke
>> >>din.com%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%2Fin%2Fpiotr-zarzycki-
>> 92a53552&data=02%7C01%7C%7Cab4e20a981d4
>> >>4a9
>> >>ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422
>> 2
>> >>459
>> >>42183624&sdata=tSGDWZ5AhBPECbf1%2Fy9R2u9N4qwJ03VBhzwzNsPTcCM%3D&reser
>> v
>> >>ed=
>> >>0>
>> >>
>> >> GitHub:
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>> u
>> >>b.c
>> >>om%2Fpiotrzarzycki21&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>> 8
>> >>8%7
>> >>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=
>> l
>> >>Mum
>> >>yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0
>> >
>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Mark Kessler <ke...@gmail.com>.
It's a good idea. Would definitely make a transition easier if I
could plan out over time. Being able to stage changes to migrate more
easily would be welcome.
-Mark K
On Fri, Sep 29, 2017 at 2:40 PM, Peter Ent <pe...@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" <ng...@idylog.com> wrote:
>
Re: [Royale] Flex to FlexJS migration path
Posted by Peter Ent <pe...@adobe.com.INVALID>.
I'm working on a sample page based on this idea. I hope to have at least
two different ways of presenting this information from which to choose. I
will publish it on my home.apache.org site as soon as it is completed.
—peter
On 9/30/17, 7:47 AM, "Idylog - Nicolas Granon" <ng...@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
>> <pi...@gmail.com>>
>> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
>> <us...@royale.apache.org>>
>> Date: Friday, September 29, 2017 at 5:00 PM
>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>> <us...@royale.apache.org>>,
>> "users@flex.apache.org<ma...@flex.apache.org>"
>> <us...@flex.apache.org>>,
>> "ngranon@idylog.com<ma...@idylog.com>"
>> <ng...@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
>> <ah...@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"
>> <pe...@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"
>> <ng...@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<ma...@adobe.com.INVALID>]
>> >>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>> >>> users@flex.apache.org<ma...@flex.apache.org>;
>> >>> ngranon@idylog.com<ma...@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"
>> >>> <ng...@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<ma...@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
>> >>> >> <ng...@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
>> >>> >
>> >>
>> >>
>> >
>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Peter Ent <pe...@adobe.com>.
We'd need a map back to the Flex components. That would not be too hard as
long as we don't need any or much commentary about the Flex side. That's
what I was going for in the table.
I put in a couple of extra components but do not want to take writing out
everything in an HTML table without gather alternative ideas, like using
ASDocs. I'll see what I can do to come up with a prototype app.
—peter
On 10/3/17, 4:47 PM, "Alex Harui" <ah...@adobe.com> wrote:
>Sounds worth a try. Note that Royale ASDoc is currently a Royale app.
>Also note that regular Flex used [Alternative] metadata to point from MX
>components to Spark components. I think we want the opposite, though, and
>point from Royale components back to MX and Spark components.
>
>I believe that any new asdoc tags or metadata goes in the JSON files used
>by the Royale ASDoc app so data should be easy to create.
>
>HTH,
>-Alex
>
>On 10/3/17, 1:33 PM, "Harbs" <ha...@gmail.com> wrote:
>
>>Hmm. Thinking about it some more, I’m thinking that a Royale app to
>>display the data could be a very good idea. It could solve the real
>>estate problem and make finding options very easy.
>>
>>Basically, you could either browse for search for a mx or spark component
>>and you could then get a picker for all the component sets which have a
>>match. As we build out our component sets there could be multiple matches
>>or alternates.
>>
>>We’d have to come up with a data format for finding references to
>>matching or alternative components. Ideally this would be info that’s
>>pulled from the ASDoc output.
>>
>>Thoughts?
>>
>>> On Oct 3, 2017, at 11:22 PM, Harbs <ha...@gmail.com> wrote:
>>>
>>> GH Pages is likely the way to go. Maybe we could make the comparison an
>>>interactive Royale app… ;-)
>>>
>>>> On Oct 3, 2017, at 11:18 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>
>>>> OK, maybe wait until royale-docs is up and try GH Pages? Or if it is
>>>> better as plain HTML, put it on royale.a.o?
>>>>
>>>> -Alex
>>>>
>>>> On 10/3/17, 1:13 PM, "Harbs" <ha...@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 <pe...@adobe.com> wrote:
>>>>>>
>>>>>> I have a quick sample web page up at:
>>>>>>
>>>>>>
>>>>>>
>>>>>>https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fhome.ap
>>>>>>a
>>>>>>che
>>>>>>
>>>>>>.org%2F~pent%2FFlex2Royale%2F&data=02%7C01%7C%7C8a812742e9fc437f94450
>>>>>>8
>>>>>>d50
>>>>>>
>>>>>>a9b42ed%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364265843131723
>>>>>>7
>>>>>>3&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" <ng...@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
>>>>>>>> <pi...@gmail.com>>
>>>>>>>> Reply-To:
>>>>>>>>"users@royale.apache.org<ma...@royale.apache.org>"
>>>>>>>> <us...@royale.apache.org>>
>>>>>>>> Date: Friday, September 29, 2017 at 5:00 PM
>>>>>>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>>>>> <us...@royale.apache.org>>,
>>>>>>>> "users@flex.apache.org<ma...@flex.apache.org>"
>>>>>>>> <us...@flex.apache.org>>,
>>>>>>>> "ngranon@idylog.com<ma...@idylog.com>"
>>>>>>>> <ng...@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
>>>>>>>> <ah...@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"
>>>>>>>> <pe...@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"
>>>>>>>> <ng...@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<ma...@flex.apache.org>;
>>>>>>>>>>> ngranon@idylog.com<ma...@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"
>>>>>>>>>>> <ng...@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<ma...@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%2F
>>>>>>>>>>c
>>>>>>>>>>>>> wik
>>>>>>>>>>> i
>>>>>>>>>>>>> .ap
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%
>>>>>>>>>>3
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796478
>>>>>>>>>>8
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&
>>>>>>>>>>s
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>
>>>>>>>>>>%
>>>>>>>>>>>>> 2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d
>>>>>>>>>>> a
>>>>>>>>>>>>> ta=
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b3443879
>>>>>>>>>>4
>>>>>>>>>>>>> aed
>>>>>>>>>>> 2
>>>>>>>>>>>>> c17
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3Xr
>>>>>>>>>>u
>>>>>>>>>>>>> u84
>>>>>>>>>>> A
>>>>>>>>>>>>> q88
>>>>>>>>>>>>> 7xFTPSj2DuB%2B0%3D&reserved=0
>>>>>>>>>>>>> es+and+Layouts
>>>>>>>>>>>>> [2]
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>g
>>>>>>>>>>>>> ith
>>>>>>>>>>> u
>>>>>>>>>>>>> b.c
>>>>>>>>>>>>> om%2Fapache%2Froyale-
>>>>>>>>>>> asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs&data=02
>>>>>>>>>>>>> %7C
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2
>>>>>>>>>>c
>>>>>>>>>>>>> 178
>>>>>>>>>>> d
>>>>>>>>>>>>> ece
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR6M
>>>>>>>>>>D
>>>>>>>>>>>>> c%2
>>>>>>>>>>> B
>>>>>>>>>>>>> t1Y
>>>>>>>>>>>>> YMHGPVL7jA%3D&reserved=0
>>>>>>>>>>>>> [3]
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>g
>>>>>>>>>>>>> ith
>>>>>>>>>>> u
>>>>>>>>>>>>> b.c
>>>>>>>>>>>>> om%2Fapache%2Froyale-
>>>>>>>>>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>>>>>>>>>>>> 88%
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&s
>>>>>>>>>>d
>>>>>>>>>>>>> ata
>>>>>>>>>>> =
>>>>>>>>>>>>> xB2
>>>>>>>>>>>>> 5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apa
>>>>>>>>>>c
>>>>>>>>>>>>> he/
>>>>>>>>>>> f
>>>>>>>>>>>>> l
>>>>>>>>>>>>> ex/html
>>>>>>>>>>>>> [4]
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>c
>>>>>>>>>>>>> wik
>>>>>>>>>>> i
>>>>>>>>>>>>> .ap
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%
>>>>>>>>>>3
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796478
>>>>>>>>>>8
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&
>>>>>>>>>>s
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>
>>>>>>>>>>%
>>>>>>>>>>>>> 2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat
>>>>>>>>>>> a
>>>>>>>>>>>>> =02
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794a
>>>>>>>>>>e
>>>>>>>>>>>>> d2c
>>>>>>>>>>> 1
>>>>>>>>>>>>> 78d
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7a8
>>>>>>>>>>l
>>>>>>>>>>>>> QTz
>>>>>>>>>>> L
>>>>>>>>>>>>> 8KG
>>>>>>>>>>>>> N7kM0uCu2z4%3D&reserved=0
>>>>>>>>>>>>> 28
>>>>>>>>>>>>> [5]
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>g
>>>>>>>>>>>>> ith
>>>>>>>>>>> u
>>>>>>>>>>>>> b.c
>>>>>>>>>>>>> om%2Fapache%2Froyale-
>>>>>>>>>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>>>>>>>>>>>> 88%
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&s
>>>>>>>>>>d
>>>>>>>>>>>>> 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%2F
>>>>>>>>>>g
>>>>>>>>>>>>> ith
>>>>>>>>>>> u
>>>>>>>>>>>>> b.c
>>>>>>>>>>>>> om%2Fapache%2Froyale-
>>>>>>>>>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>>>>>>>>>>>> 88%
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&s
>>>>>>>>>>d
>>>>>>>>>>>>> ata
>>>>>>>>>>> =
>>>>>>>>>>>>> xB2
>>>>>>>>>>>>> 5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>>>>>>>>>>>>> asjs/tree/develop/examples/flexjs/MDLExample
>>>>>>>>>>>>> [7]
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>g
>>>>>>>>>>>>> etm
>>>>>>>>>>> d
>>>>>>>>>>>>> l.i
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>o%2Fcomponents%2Findex.html&data=02%7C01%7C%7Cab4e20a981d44a9ea01
>>>>>>>>>>4
>>>>>>>>>>>>> 08d
>>>>>>>>>>> 5
>>>>>>>>>>>>> 06a
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642224594218
>>>>>>>>>>3
>>>>>>>>>>>>> 624
>>>>>>>>>>> &
>>>>>>>>>>>>> sda
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ta=U6IQ%2Fikcn61Row6PjP%2FLF%2F4kqle2pe4U%2BEgAuxMfL90%3D&reserve
>>>>>>>>>>d
>>>>>>>>>>>>> =0
>>>>>>>>>>>>> [8]
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>c
>>>>>>>>>>>>> wik
>>>>>>>>>>> i
>>>>>>>>>>>>> .ap
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%
>>>>>>>>>>3
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796478
>>>>>>>>>>8
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&
>>>>>>>>>>s
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>
>>>>>>>>>>%
>>>>>>>>>>>>> 2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data
>>>>>>>>>>> =
>>>>>>>>>>>>> 02%
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794ae
>>>>>>>>>>d
>>>>>>>>>>>>> 2c1
>>>>>>>>>>> 7
>>>>>>>>>>>>> 8de
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xRtJ
>>>>>>>>>>r
>>>>>>>>>>>>> dXn
>>>>>>>>>>> D
>>>>>>>>>>>>> Lai
>>>>>>>>>>>>> 3UM8LpiO7APc%3D&reserved=0
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks, Piotr
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2017-09-28 17:58 GMT+02:00 Idylog - Nicolas Granon
>>>>>>>>>>>>> <ng...@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%2F
>>>>>>>>>>c
>>>>>>>>>>>>> wik
>>>>>>>>>>> i
>>>>>>>>>>>>> .ap
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%
>>>>>>>>>>3
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796478
>>>>>>>>>>8
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&
>>>>>>>>>>s
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>
>>>>>>>>>>%
>>>>>>>>>>>>> 2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0
>>>>>>>>>>> 2
>>>>>>>>>>>>> %7C
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2
>>>>>>>>>>c
>>>>>>>>>>>>> 178
>>>>>>>>>>> d
>>>>>>>>>>>>> ece
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoLzL
>>>>>>>>>>H
>>>>>>>>>>>>> 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%2Fw
>>>>>>>>>>w
>>>>>>>>>>>>> w.l
>>>>>>>>>>> i
>>>>>>>>>>>>> nke
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>din.com<https://na01.safelinks.protection.outlook.com/?url=http%3
>>>>>>>>>>A
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%2F%2Fdin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788%
>>>>>>>>>>7
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&sd
>>>>>>>>>>a
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ta=B7M%2BhYPAUN%2FwIEe4DoMPpIjTZhxpwoTlKNrD%2FZaqkAg%3D&reserved=
>>>>>>>>>>0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>%2Fpiotrzarzycki&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506
>>>>>>>>>>>>>>a
>>>>>>>>>>> 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%2
>>>>>>>>>>F
>>>>>>>>>>pl.
>>>>>>>>>>> l
>>>>>>>>>>>>> ink
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>edin.com<https://na01.safelinks.protection.outlook.com/?url=http%
>>>>>>>>>>3
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>A%2F%2Fedin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796478
>>>>>>>>>>8
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%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%7C63
>>>>>>>>>>6
>>>>>>>>>>>>> 422
>>>>>>>>>>> 2
>>>>>>>>>>>>> 459
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>42183624&sdata=tSGDWZ5AhBPECbf1%2Fy9R2u9N4qwJ03VBhzwzNsPTcCM%3D&r
>>>>>>>>>>e
>>>>>>>>>>>>> ser
>>>>>>>>>>> v
>>>>>>>>>>>>> ed=
>>>>>>>>>>>>> 0>
>>>>>>>>>>>>>
>>>>>>>>>>>>> GitHub:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>g
>>>>>>>>>>>>> ith
>>>>>>>>>>> u
>>>>>>>>>>>>> b.c
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>om%2Fpiotrzarzycki21&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506
>>>>>>>>>>a
>>>>>>>>>>>>> 926
>>>>>>>>>>> 8
>>>>>>>>>>>>> 8%7
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sd
>>>>>>>>>>a
>>>>>>>>>>>>> ta=
>>>>>>>>>>> l
>>>>>>>>>>>>> Mum
>>>>>>>>>>>>> yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Peter Ent <pe...@adobe.com.INVALID>.
We'd need a map back to the Flex components. That would not be too hard as
long as we don't need any or much commentary about the Flex side. That's
what I was going for in the table.
I put in a couple of extra components but do not want to take writing out
everything in an HTML table without gather alternative ideas, like using
ASDocs. I'll see what I can do to come up with a prototype app.
—peter
On 10/3/17, 4:47 PM, "Alex Harui" <ah...@adobe.com> wrote:
>Sounds worth a try. Note that Royale ASDoc is currently a Royale app.
>Also note that regular Flex used [Alternative] metadata to point from MX
>components to Spark components. I think we want the opposite, though, and
>point from Royale components back to MX and Spark components.
>
>I believe that any new asdoc tags or metadata goes in the JSON files used
>by the Royale ASDoc app so data should be easy to create.
>
>HTH,
>-Alex
>
>On 10/3/17, 1:33 PM, "Harbs" <ha...@gmail.com> wrote:
>
>>Hmm. Thinking about it some more, I’m thinking that a Royale app to
>>display the data could be a very good idea. It could solve the real
>>estate problem and make finding options very easy.
>>
>>Basically, you could either browse for search for a mx or spark component
>>and you could then get a picker for all the component sets which have a
>>match. As we build out our component sets there could be multiple matches
>>or alternates.
>>
>>We’d have to come up with a data format for finding references to
>>matching or alternative components. Ideally this would be info that’s
>>pulled from the ASDoc output.
>>
>>Thoughts?
>>
>>> On Oct 3, 2017, at 11:22 PM, Harbs <ha...@gmail.com> wrote:
>>>
>>> GH Pages is likely the way to go. Maybe we could make the comparison an
>>>interactive Royale app… ;-)
>>>
>>>> On Oct 3, 2017, at 11:18 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>
>>>> OK, maybe wait until royale-docs is up and try GH Pages? Or if it is
>>>> better as plain HTML, put it on royale.a.o?
>>>>
>>>> -Alex
>>>>
>>>> On 10/3/17, 1:13 PM, "Harbs" <ha...@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 <pe...@adobe.com> wrote:
>>>>>>
>>>>>> I have a quick sample web page up at:
>>>>>>
>>>>>>
>>>>>>
>>>>>>https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fhome.ap
>>>>>>a
>>>>>>che
>>>>>>
>>>>>>.org%2F~pent%2FFlex2Royale%2F&data=02%7C01%7C%7C8a812742e9fc437f94450
>>>>>>8
>>>>>>d50
>>>>>>
>>>>>>a9b42ed%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364265843131723
>>>>>>7
>>>>>>3&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" <ng...@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
>>>>>>>> <pi...@gmail.com>>
>>>>>>>> Reply-To:
>>>>>>>>"users@royale.apache.org<ma...@royale.apache.org>"
>>>>>>>> <us...@royale.apache.org>>
>>>>>>>> Date: Friday, September 29, 2017 at 5:00 PM
>>>>>>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>>>>> <us...@royale.apache.org>>,
>>>>>>>> "users@flex.apache.org<ma...@flex.apache.org>"
>>>>>>>> <us...@flex.apache.org>>,
>>>>>>>> "ngranon@idylog.com<ma...@idylog.com>"
>>>>>>>> <ng...@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
>>>>>>>> <ah...@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"
>>>>>>>> <pe...@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"
>>>>>>>> <ng...@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<ma...@flex.apache.org>;
>>>>>>>>>>> ngranon@idylog.com<ma...@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"
>>>>>>>>>>> <ng...@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<ma...@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%2F
>>>>>>>>>>c
>>>>>>>>>>>>> wik
>>>>>>>>>>> i
>>>>>>>>>>>>> .ap
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%
>>>>>>>>>>3
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796478
>>>>>>>>>>8
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&
>>>>>>>>>>s
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>
>>>>>>>>>>%
>>>>>>>>>>>>> 2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d
>>>>>>>>>>> a
>>>>>>>>>>>>> ta=
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b3443879
>>>>>>>>>>4
>>>>>>>>>>>>> aed
>>>>>>>>>>> 2
>>>>>>>>>>>>> c17
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3Xr
>>>>>>>>>>u
>>>>>>>>>>>>> u84
>>>>>>>>>>> A
>>>>>>>>>>>>> q88
>>>>>>>>>>>>> 7xFTPSj2DuB%2B0%3D&reserved=0
>>>>>>>>>>>>> es+and+Layouts
>>>>>>>>>>>>> [2]
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>g
>>>>>>>>>>>>> ith
>>>>>>>>>>> u
>>>>>>>>>>>>> b.c
>>>>>>>>>>>>> om%2Fapache%2Froyale-
>>>>>>>>>>> asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs&data=02
>>>>>>>>>>>>> %7C
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2
>>>>>>>>>>c
>>>>>>>>>>>>> 178
>>>>>>>>>>> d
>>>>>>>>>>>>> ece
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR6M
>>>>>>>>>>D
>>>>>>>>>>>>> c%2
>>>>>>>>>>> B
>>>>>>>>>>>>> t1Y
>>>>>>>>>>>>> YMHGPVL7jA%3D&reserved=0
>>>>>>>>>>>>> [3]
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>g
>>>>>>>>>>>>> ith
>>>>>>>>>>> u
>>>>>>>>>>>>> b.c
>>>>>>>>>>>>> om%2Fapache%2Froyale-
>>>>>>>>>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>>>>>>>>>>>> 88%
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&s
>>>>>>>>>>d
>>>>>>>>>>>>> ata
>>>>>>>>>>> =
>>>>>>>>>>>>> xB2
>>>>>>>>>>>>> 5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apa
>>>>>>>>>>c
>>>>>>>>>>>>> he/
>>>>>>>>>>> f
>>>>>>>>>>>>> l
>>>>>>>>>>>>> ex/html
>>>>>>>>>>>>> [4]
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>c
>>>>>>>>>>>>> wik
>>>>>>>>>>> i
>>>>>>>>>>>>> .ap
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%
>>>>>>>>>>3
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796478
>>>>>>>>>>8
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&
>>>>>>>>>>s
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>
>>>>>>>>>>%
>>>>>>>>>>>>> 2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat
>>>>>>>>>>> a
>>>>>>>>>>>>> =02
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794a
>>>>>>>>>>e
>>>>>>>>>>>>> d2c
>>>>>>>>>>> 1
>>>>>>>>>>>>> 78d
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7a8
>>>>>>>>>>l
>>>>>>>>>>>>> QTz
>>>>>>>>>>> L
>>>>>>>>>>>>> 8KG
>>>>>>>>>>>>> N7kM0uCu2z4%3D&reserved=0
>>>>>>>>>>>>> 28
>>>>>>>>>>>>> [5]
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>g
>>>>>>>>>>>>> ith
>>>>>>>>>>> u
>>>>>>>>>>>>> b.c
>>>>>>>>>>>>> om%2Fapache%2Froyale-
>>>>>>>>>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>>>>>>>>>>>> 88%
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&s
>>>>>>>>>>d
>>>>>>>>>>>>> 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%2F
>>>>>>>>>>g
>>>>>>>>>>>>> ith
>>>>>>>>>>> u
>>>>>>>>>>>>> b.c
>>>>>>>>>>>>> om%2Fapache%2Froyale-
>>>>>>>>>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>>>>>>>>>>>> 88%
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&s
>>>>>>>>>>d
>>>>>>>>>>>>> ata
>>>>>>>>>>> =
>>>>>>>>>>>>> xB2
>>>>>>>>>>>>> 5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>>>>>>>>>>>>> asjs/tree/develop/examples/flexjs/MDLExample
>>>>>>>>>>>>> [7]
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>g
>>>>>>>>>>>>> etm
>>>>>>>>>>> d
>>>>>>>>>>>>> l.i
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>o%2Fcomponents%2Findex.html&data=02%7C01%7C%7Cab4e20a981d44a9ea01
>>>>>>>>>>4
>>>>>>>>>>>>> 08d
>>>>>>>>>>> 5
>>>>>>>>>>>>> 06a
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642224594218
>>>>>>>>>>3
>>>>>>>>>>>>> 624
>>>>>>>>>>> &
>>>>>>>>>>>>> sda
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ta=U6IQ%2Fikcn61Row6PjP%2FLF%2F4kqle2pe4U%2BEgAuxMfL90%3D&reserve
>>>>>>>>>>d
>>>>>>>>>>>>> =0
>>>>>>>>>>>>> [8]
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>c
>>>>>>>>>>>>> wik
>>>>>>>>>>> i
>>>>>>>>>>>>> .ap
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%
>>>>>>>>>>3
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796478
>>>>>>>>>>8
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&
>>>>>>>>>>s
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>
>>>>>>>>>>%
>>>>>>>>>>>>> 2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data
>>>>>>>>>>> =
>>>>>>>>>>>>> 02%
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794ae
>>>>>>>>>>d
>>>>>>>>>>>>> 2c1
>>>>>>>>>>> 7
>>>>>>>>>>>>> 8de
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xRtJ
>>>>>>>>>>r
>>>>>>>>>>>>> dXn
>>>>>>>>>>> D
>>>>>>>>>>>>> Lai
>>>>>>>>>>>>> 3UM8LpiO7APc%3D&reserved=0
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks, Piotr
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2017-09-28 17:58 GMT+02:00 Idylog - Nicolas Granon
>>>>>>>>>>>>> <ng...@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%2F
>>>>>>>>>>c
>>>>>>>>>>>>> wik
>>>>>>>>>>> i
>>>>>>>>>>>>> .ap
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%
>>>>>>>>>>3
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796478
>>>>>>>>>>8
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&
>>>>>>>>>>s
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>
>>>>>>>>>>%
>>>>>>>>>>>>> 2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0
>>>>>>>>>>> 2
>>>>>>>>>>>>> %7C
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2
>>>>>>>>>>c
>>>>>>>>>>>>> 178
>>>>>>>>>>> d
>>>>>>>>>>>>> ece
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoLzL
>>>>>>>>>>H
>>>>>>>>>>>>> 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%2Fw
>>>>>>>>>>w
>>>>>>>>>>>>> w.l
>>>>>>>>>>> i
>>>>>>>>>>>>> nke
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>din.com<https://na01.safelinks.protection.outlook.com/?url=http%3
>>>>>>>>>>A
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%2F%2Fdin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788%
>>>>>>>>>>7
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&sd
>>>>>>>>>>a
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ta=B7M%2BhYPAUN%2FwIEe4DoMPpIjTZhxpwoTlKNrD%2FZaqkAg%3D&reserved=
>>>>>>>>>>0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>%2Fpiotrzarzycki&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506
>>>>>>>>>>>>>>a
>>>>>>>>>>> 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%2
>>>>>>>>>>F
>>>>>>>>>>pl.
>>>>>>>>>>> l
>>>>>>>>>>>>> ink
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>edin.com<https://na01.safelinks.protection.outlook.com/?url=http%
>>>>>>>>>>3
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>A%2F%2Fedin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796478
>>>>>>>>>>8
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%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%7C63
>>>>>>>>>>6
>>>>>>>>>>>>> 422
>>>>>>>>>>> 2
>>>>>>>>>>>>> 459
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>42183624&sdata=tSGDWZ5AhBPECbf1%2Fy9R2u9N4qwJ03VBhzwzNsPTcCM%3D&r
>>>>>>>>>>e
>>>>>>>>>>>>> ser
>>>>>>>>>>> v
>>>>>>>>>>>>> ed=
>>>>>>>>>>>>> 0>
>>>>>>>>>>>>>
>>>>>>>>>>>>> GitHub:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>g
>>>>>>>>>>>>> ith
>>>>>>>>>>> u
>>>>>>>>>>>>> b.c
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>om%2Fpiotrzarzycki21&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506
>>>>>>>>>>a
>>>>>>>>>>>>> 926
>>>>>>>>>>> 8
>>>>>>>>>>>>> 8%7
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sd
>>>>>>>>>>a
>>>>>>>>>>>>> ta=
>>>>>>>>>>> l
>>>>>>>>>>>>> Mum
>>>>>>>>>>>>> yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Great idea Peter, it makes very clear to users about the components, beads
and it's very easy to view.
Maybe as the list grows could have a usability problem. Maybe solved with
some kind of menu that presents the required bits of information selected.
2017-10-03 22:47 GMT+02:00 Alex Harui <ah...@adobe.com>:
> Sounds worth a try. Note that Royale ASDoc is currently a Royale app.
> Also note that regular Flex used [Alternative] metadata to point from MX
> components to Spark components. I think we want the opposite, though, and
> point from Royale components back to MX and Spark components.
>
> I believe that any new asdoc tags or metadata goes in the JSON files used
> by the Royale ASDoc app so data should be easy to create.
>
> HTH,
> -Alex
>
> On 10/3/17, 1:33 PM, "Harbs" <ha...@gmail.com> wrote:
>
> >Hmm. Thinking about it some more, I’m thinking that a Royale app to
> >display the data could be a very good idea. It could solve the real
> >estate problem and make finding options very easy.
> >
> >Basically, you could either browse for search for a mx or spark component
> >and you could then get a picker for all the component sets which have a
> >match. As we build out our component sets there could be multiple matches
> >or alternates.
> >
> >We’d have to come up with a data format for finding references to
> >matching or alternative components. Ideally this would be info that’s
> >pulled from the ASDoc output.
> >
> >Thoughts?
> >
> >> On Oct 3, 2017, at 11:22 PM, Harbs <ha...@gmail.com> wrote:
> >>
> >> GH Pages is likely the way to go. Maybe we could make the comparison an
> >>interactive Royale app… ;-)
> >>
> >>> On Oct 3, 2017, at 11:18 PM, Alex Harui <ah...@adobe.com> wrote:
> >>>
> >>> OK, maybe wait until royale-docs is up and try GH Pages? Or if it is
> >>> better as plain HTML, put it on royale.a.o?
> >>>
> >>> -Alex
> >>>
> >>> On 10/3/17, 1:13 PM, "Harbs" <ha...@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 <pe...@adobe.com> wrote:
> >>>>>
> >>>>> I have a quick sample web page up at:
> >>>>>
> >>>>>
> >>>>>
> >>>>>https://na01.safelinks.protection.outlook.com/?url=
> http:%2F%2Fhome.apa
> >>>>>che
> >>>>>
> >>>>>.org%2F~pent%2FFlex2Royale%2F&data=02%7C01%
> 7C%7C8a812742e9fc437f944508
> >>>>>d50
> >>>>>
> >>>>>a9b42ed%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C63642658431317237
> >>>>>3&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" <ng...@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
> >>>>>>> <pi...@gmail.com>>
> >>>>>>> Reply-To: "users@royale.apache.org<mailto:users@royale.apache.org
> >"
> >>>>>>> <us...@royale.apache.org>>
> >>>>>>> Date: Friday, September 29, 2017 at 5:00 PM
> >>>>>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
> >>>>>>> <us...@royale.apache.org>>,
> >>>>>>> "users@flex.apache.org<ma...@flex.apache.org>"
> >>>>>>> <us...@flex.apache.org>>,
> >>>>>>> "ngranon@idylog.com<ma...@idylog.com>"
> >>>>>>> <ng...@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
> >>>>>>> <ah...@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"
> >>>>>>> <pe...@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"
> >>>>>>> <ng...@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<ma...@flex.apache.org>;
> >>>>>>>>>> ngranon@idylog.com<ma...@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"
> >>>>>>>>>> <ng...@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<ma...@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%7C8514d1b1725d45e0a5b908d50796
> 4788
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636423264392032256&s
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ
> 9WZzj943DSgJHg%3D&reserved=0>%
> >>>>>>>>>>>> 2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d
> >>>>>>>>>> a
> >>>>>>>>>>>> ta=
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a9
> 2688%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%7Cab4e20a981d44a9ea01408d506a9
> 2688%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%7C8514d1b1725d45e0a5b908d50796
> 4788
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636423264392032256&s
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ
> 9WZzj943DSgJHg%3D&reserved=0>%
> >>>>>>>>>>>> 2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat
> >>>>>>>>>> a
> >>>>>>>>>>>> =02
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>%7C01%7C%7Cab4e20a981d44a9ea01408d506a9
> 2688%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%7Cfa7b1b5a7b34438794aed2c178de
> cee1%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%7C8514d1b1725d45e0a5b908d50796
> 4788
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636423264392032256&s
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ
> 9WZzj943DSgJHg%3D&reserved=0>%
> >>>>>>>>>>>> 2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data
> >>>>>>>>>> =
> >>>>>>>>>>>> 02%
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>7C01%7C%7Cab4e20a981d44a9ea01408d506a9
> 2688%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
> >>>>>>>>>>>> <ng...@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%7C8514d1b1725d45e0a5b908d50796
> 4788
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636423264392032256&s
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ
> 9WZzj943DSgJHg%3D&reserved=0>%
> >>>>>>>>>>>> 2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0
> >>>>>>>>>> 2
> >>>>>>>>>>>> %7C
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>01%7C%7Cab4e20a981d44a9ea01408d506a9
> 2688%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%7C8514d1b1725d45e0a5b908d50796
> 4788%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%2F
> >>>>>>>>>pl.
> >>>>>>>>>> l
> >>>>>>>>>>>> ink
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>edin.com<https://na01.safelinks.protection.
> outlook.com/?url=http%3
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>A%2F%2Fedin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796
> 4788
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636423264392032256&s
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>data=7rUvU4thZJ3Ja1S4aMg4RwxKGwoMgN4%2FIZ4RY9W4MwE%3D&reserved=0>
> %
> >>>>>>>>>>>> 2Fin%2Fpiotr-zarzycki-
> >>>>>>>>>> 92a53552&data=02%7C01%7C%7Cab4e20a981d4
> >>>>>>>>>>>> 4a9
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178de
> cee1%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
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> >
>
>
--
<http://www.codeoscopic.com>
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.
De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.
Re: [Royale] Flex to FlexJS migration path
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Great idea Peter, it makes very clear to users about the components, beads
and it's very easy to view.
Maybe as the list grows could have a usability problem. Maybe solved with
some kind of menu that presents the required bits of information selected.
2017-10-03 22:47 GMT+02:00 Alex Harui <ah...@adobe.com>:
> Sounds worth a try. Note that Royale ASDoc is currently a Royale app.
> Also note that regular Flex used [Alternative] metadata to point from MX
> components to Spark components. I think we want the opposite, though, and
> point from Royale components back to MX and Spark components.
>
> I believe that any new asdoc tags or metadata goes in the JSON files used
> by the Royale ASDoc app so data should be easy to create.
>
> HTH,
> -Alex
>
> On 10/3/17, 1:33 PM, "Harbs" <ha...@gmail.com> wrote:
>
> >Hmm. Thinking about it some more, I’m thinking that a Royale app to
> >display the data could be a very good idea. It could solve the real
> >estate problem and make finding options very easy.
> >
> >Basically, you could either browse for search for a mx or spark component
> >and you could then get a picker for all the component sets which have a
> >match. As we build out our component sets there could be multiple matches
> >or alternates.
> >
> >We’d have to come up with a data format for finding references to
> >matching or alternative components. Ideally this would be info that’s
> >pulled from the ASDoc output.
> >
> >Thoughts?
> >
> >> On Oct 3, 2017, at 11:22 PM, Harbs <ha...@gmail.com> wrote:
> >>
> >> GH Pages is likely the way to go. Maybe we could make the comparison an
> >>interactive Royale app… ;-)
> >>
> >>> On Oct 3, 2017, at 11:18 PM, Alex Harui <ah...@adobe.com> wrote:
> >>>
> >>> OK, maybe wait until royale-docs is up and try GH Pages? Or if it is
> >>> better as plain HTML, put it on royale.a.o?
> >>>
> >>> -Alex
> >>>
> >>> On 10/3/17, 1:13 PM, "Harbs" <ha...@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 <pe...@adobe.com> wrote:
> >>>>>
> >>>>> I have a quick sample web page up at:
> >>>>>
> >>>>>
> >>>>>
> >>>>>https://na01.safelinks.protection.outlook.com/?url=
> http:%2F%2Fhome.apa
> >>>>>che
> >>>>>
> >>>>>.org%2F~pent%2FFlex2Royale%2F&data=02%7C01%
> 7C%7C8a812742e9fc437f944508
> >>>>>d50
> >>>>>
> >>>>>a9b42ed%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C63642658431317237
> >>>>>3&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" <ng...@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
> >>>>>>> <pi...@gmail.com>>
> >>>>>>> Reply-To: "users@royale.apache.org<mailto:users@royale.apache.org
> >"
> >>>>>>> <us...@royale.apache.org>>
> >>>>>>> Date: Friday, September 29, 2017 at 5:00 PM
> >>>>>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
> >>>>>>> <us...@royale.apache.org>>,
> >>>>>>> "users@flex.apache.org<ma...@flex.apache.org>"
> >>>>>>> <us...@flex.apache.org>>,
> >>>>>>> "ngranon@idylog.com<ma...@idylog.com>"
> >>>>>>> <ng...@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
> >>>>>>> <ah...@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"
> >>>>>>> <pe...@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"
> >>>>>>> <ng...@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<ma...@flex.apache.org>;
> >>>>>>>>>> ngranon@idylog.com<ma...@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"
> >>>>>>>>>> <ng...@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<ma...@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%7C8514d1b1725d45e0a5b908d50796
> 4788
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636423264392032256&s
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ
> 9WZzj943DSgJHg%3D&reserved=0>%
> >>>>>>>>>>>> 2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d
> >>>>>>>>>> a
> >>>>>>>>>>>> ta=
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a9
> 2688%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%7Cab4e20a981d44a9ea01408d506a9
> 2688%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%7C8514d1b1725d45e0a5b908d50796
> 4788
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636423264392032256&s
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ
> 9WZzj943DSgJHg%3D&reserved=0>%
> >>>>>>>>>>>> 2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat
> >>>>>>>>>> a
> >>>>>>>>>>>> =02
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>%7C01%7C%7Cab4e20a981d44a9ea01408d506a9
> 2688%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%7Cfa7b1b5a7b34438794aed2c178de
> cee1%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%7C8514d1b1725d45e0a5b908d50796
> 4788
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636423264392032256&s
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ
> 9WZzj943DSgJHg%3D&reserved=0>%
> >>>>>>>>>>>> 2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data
> >>>>>>>>>> =
> >>>>>>>>>>>> 02%
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>7C01%7C%7Cab4e20a981d44a9ea01408d506a9
> 2688%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
> >>>>>>>>>>>> <ng...@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%7C8514d1b1725d45e0a5b908d50796
> 4788
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636423264392032256&s
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ
> 9WZzj943DSgJHg%3D&reserved=0>%
> >>>>>>>>>>>> 2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0
> >>>>>>>>>> 2
> >>>>>>>>>>>> %7C
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>01%7C%7Cab4e20a981d44a9ea01408d506a9
> 2688%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%7C8514d1b1725d45e0a5b908d50796
> 4788%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%2F
> >>>>>>>>>pl.
> >>>>>>>>>> l
> >>>>>>>>>>>> ink
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>edin.com<https://na01.safelinks.protection.
> outlook.com/?url=http%3
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>A%2F%2Fedin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796
> 4788
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636423264392032256&s
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>data=7rUvU4thZJ3Ja1S4aMg4RwxKGwoMgN4%2FIZ4RY9W4MwE%3D&reserved=0>
> %
> >>>>>>>>>>>> 2Fin%2Fpiotr-zarzycki-
> >>>>>>>>>> 92a53552&data=02%7C01%7C%7Cab4e20a981d4
> >>>>>>>>>>>> 4a9
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178de
> cee1%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
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> >
>
>
--
<http://www.codeoscopic.com>
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.
De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.
Re: [Royale] Flex to FlexJS migration path
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Great idea Peter, it makes very clear to users about the components, beads
and it's very easy to view.
Maybe as the list grows could have a usability problem. Maybe solved with
some kind of menu that presents the required bits of information selected.
2017-10-03 22:47 GMT+02:00 Alex Harui <ah...@adobe.com>:
> Sounds worth a try. Note that Royale ASDoc is currently a Royale app.
> Also note that regular Flex used [Alternative] metadata to point from MX
> components to Spark components. I think we want the opposite, though, and
> point from Royale components back to MX and Spark components.
>
> I believe that any new asdoc tags or metadata goes in the JSON files used
> by the Royale ASDoc app so data should be easy to create.
>
> HTH,
> -Alex
>
> On 10/3/17, 1:33 PM, "Harbs" <ha...@gmail.com> wrote:
>
> >Hmm. Thinking about it some more, I’m thinking that a Royale app to
> >display the data could be a very good idea. It could solve the real
> >estate problem and make finding options very easy.
> >
> >Basically, you could either browse for search for a mx or spark component
> >and you could then get a picker for all the component sets which have a
> >match. As we build out our component sets there could be multiple matches
> >or alternates.
> >
> >We’d have to come up with a data format for finding references to
> >matching or alternative components. Ideally this would be info that’s
> >pulled from the ASDoc output.
> >
> >Thoughts?
> >
> >> On Oct 3, 2017, at 11:22 PM, Harbs <ha...@gmail.com> wrote:
> >>
> >> GH Pages is likely the way to go. Maybe we could make the comparison an
> >>interactive Royale app… ;-)
> >>
> >>> On Oct 3, 2017, at 11:18 PM, Alex Harui <ah...@adobe.com> wrote:
> >>>
> >>> OK, maybe wait until royale-docs is up and try GH Pages? Or if it is
> >>> better as plain HTML, put it on royale.a.o?
> >>>
> >>> -Alex
> >>>
> >>> On 10/3/17, 1:13 PM, "Harbs" <ha...@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 <pe...@adobe.com> wrote:
> >>>>>
> >>>>> I have a quick sample web page up at:
> >>>>>
> >>>>>
> >>>>>
> >>>>>https://na01.safelinks.protection.outlook.com/?url=
> http:%2F%2Fhome.apa
> >>>>>che
> >>>>>
> >>>>>.org%2F~pent%2FFlex2Royale%2F&data=02%7C01%
> 7C%7C8a812742e9fc437f944508
> >>>>>d50
> >>>>>
> >>>>>a9b42ed%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C63642658431317237
> >>>>>3&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" <ng...@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
> >>>>>>> <pi...@gmail.com>>
> >>>>>>> Reply-To: "users@royale.apache.org<mailto:users@royale.apache.org
> >"
> >>>>>>> <us...@royale.apache.org>>
> >>>>>>> Date: Friday, September 29, 2017 at 5:00 PM
> >>>>>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
> >>>>>>> <us...@royale.apache.org>>,
> >>>>>>> "users@flex.apache.org<ma...@flex.apache.org>"
> >>>>>>> <us...@flex.apache.org>>,
> >>>>>>> "ngranon@idylog.com<ma...@idylog.com>"
> >>>>>>> <ng...@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
> >>>>>>> <ah...@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"
> >>>>>>> <pe...@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"
> >>>>>>> <ng...@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<ma...@flex.apache.org>;
> >>>>>>>>>> ngranon@idylog.com<ma...@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"
> >>>>>>>>>> <ng...@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<ma...@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%7C8514d1b1725d45e0a5b908d50796
> 4788
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636423264392032256&s
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ
> 9WZzj943DSgJHg%3D&reserved=0>%
> >>>>>>>>>>>> 2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d
> >>>>>>>>>> a
> >>>>>>>>>>>> ta=
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a9
> 2688%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%7Cab4e20a981d44a9ea01408d506a9
> 2688%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%7C8514d1b1725d45e0a5b908d50796
> 4788
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636423264392032256&s
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ
> 9WZzj943DSgJHg%3D&reserved=0>%
> >>>>>>>>>>>> 2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat
> >>>>>>>>>> a
> >>>>>>>>>>>> =02
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>%7C01%7C%7Cab4e20a981d44a9ea01408d506a9
> 2688%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%7Cfa7b1b5a7b34438794aed2c178de
> cee1%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%7C8514d1b1725d45e0a5b908d50796
> 4788
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636423264392032256&s
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ
> 9WZzj943DSgJHg%3D&reserved=0>%
> >>>>>>>>>>>> 2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data
> >>>>>>>>>> =
> >>>>>>>>>>>> 02%
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>7C01%7C%7Cab4e20a981d44a9ea01408d506a9
> 2688%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
> >>>>>>>>>>>> <ng...@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%7C8514d1b1725d45e0a5b908d50796
> 4788
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636423264392032256&s
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ
> 9WZzj943DSgJHg%3D&reserved=0>%
> >>>>>>>>>>>> 2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0
> >>>>>>>>>> 2
> >>>>>>>>>>>> %7C
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>01%7C%7Cab4e20a981d44a9ea01408d506a9
> 2688%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%7C8514d1b1725d45e0a5b908d50796
> 4788%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%2F
> >>>>>>>>>pl.
> >>>>>>>>>> l
> >>>>>>>>>>>> ink
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>edin.com<https://na01.safelinks.protection.
> outlook.com/?url=http%3
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>A%2F%2Fedin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796
> 4788
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636423264392032256&s
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>data=7rUvU4thZJ3Ja1S4aMg4RwxKGwoMgN4%2FIZ4RY9W4MwE%3D&reserved=0>
> %
> >>>>>>>>>>>> 2Fin%2Fpiotr-zarzycki-
> >>>>>>>>>> 92a53552&data=02%7C01%7C%7Cab4e20a981d4
> >>>>>>>>>>>> 4a9
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178de
> cee1%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
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> >
>
>
--
<http://www.codeoscopic.com>
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.
De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.
Re: [Royale] Flex to FlexJS migration path
Posted by Peter Ent <pe...@adobe.com.INVALID>.
We'd need a map back to the Flex components. That would not be too hard as
long as we don't need any or much commentary about the Flex side. That's
what I was going for in the table.
I put in a couple of extra components but do not want to take writing out
everything in an HTML table without gather alternative ideas, like using
ASDocs. I'll see what I can do to come up with a prototype app.
—peter
On 10/3/17, 4:47 PM, "Alex Harui" <ah...@adobe.com> wrote:
>Sounds worth a try. Note that Royale ASDoc is currently a Royale app.
>Also note that regular Flex used [Alternative] metadata to point from MX
>components to Spark components. I think we want the opposite, though, and
>point from Royale components back to MX and Spark components.
>
>I believe that any new asdoc tags or metadata goes in the JSON files used
>by the Royale ASDoc app so data should be easy to create.
>
>HTH,
>-Alex
>
>On 10/3/17, 1:33 PM, "Harbs" <ha...@gmail.com> wrote:
>
>>Hmm. Thinking about it some more, I’m thinking that a Royale app to
>>display the data could be a very good idea. It could solve the real
>>estate problem and make finding options very easy.
>>
>>Basically, you could either browse for search for a mx or spark component
>>and you could then get a picker for all the component sets which have a
>>match. As we build out our component sets there could be multiple matches
>>or alternates.
>>
>>We’d have to come up with a data format for finding references to
>>matching or alternative components. Ideally this would be info that’s
>>pulled from the ASDoc output.
>>
>>Thoughts?
>>
>>> On Oct 3, 2017, at 11:22 PM, Harbs <ha...@gmail.com> wrote:
>>>
>>> GH Pages is likely the way to go. Maybe we could make the comparison an
>>>interactive Royale app… ;-)
>>>
>>>> On Oct 3, 2017, at 11:18 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>
>>>> OK, maybe wait until royale-docs is up and try GH Pages? Or if it is
>>>> better as plain HTML, put it on royale.a.o?
>>>>
>>>> -Alex
>>>>
>>>> On 10/3/17, 1:13 PM, "Harbs" <ha...@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 <pe...@adobe.com> wrote:
>>>>>>
>>>>>> I have a quick sample web page up at:
>>>>>>
>>>>>>
>>>>>>
>>>>>>https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fhome.ap
>>>>>>a
>>>>>>che
>>>>>>
>>>>>>.org%2F~pent%2FFlex2Royale%2F&data=02%7C01%7C%7C8a812742e9fc437f94450
>>>>>>8
>>>>>>d50
>>>>>>
>>>>>>a9b42ed%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364265843131723
>>>>>>7
>>>>>>3&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" <ng...@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
>>>>>>>> <pi...@gmail.com>>
>>>>>>>> Reply-To:
>>>>>>>>"users@royale.apache.org<ma...@royale.apache.org>"
>>>>>>>> <us...@royale.apache.org>>
>>>>>>>> Date: Friday, September 29, 2017 at 5:00 PM
>>>>>>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>>>>> <us...@royale.apache.org>>,
>>>>>>>> "users@flex.apache.org<ma...@flex.apache.org>"
>>>>>>>> <us...@flex.apache.org>>,
>>>>>>>> "ngranon@idylog.com<ma...@idylog.com>"
>>>>>>>> <ng...@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
>>>>>>>> <ah...@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"
>>>>>>>> <pe...@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"
>>>>>>>> <ng...@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<ma...@flex.apache.org>;
>>>>>>>>>>> ngranon@idylog.com<ma...@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"
>>>>>>>>>>> <ng...@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<ma...@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%2F
>>>>>>>>>>c
>>>>>>>>>>>>> wik
>>>>>>>>>>> i
>>>>>>>>>>>>> .ap
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%
>>>>>>>>>>3
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796478
>>>>>>>>>>8
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&
>>>>>>>>>>s
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>
>>>>>>>>>>%
>>>>>>>>>>>>> 2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d
>>>>>>>>>>> a
>>>>>>>>>>>>> ta=
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b3443879
>>>>>>>>>>4
>>>>>>>>>>>>> aed
>>>>>>>>>>> 2
>>>>>>>>>>>>> c17
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3Xr
>>>>>>>>>>u
>>>>>>>>>>>>> u84
>>>>>>>>>>> A
>>>>>>>>>>>>> q88
>>>>>>>>>>>>> 7xFTPSj2DuB%2B0%3D&reserved=0
>>>>>>>>>>>>> es+and+Layouts
>>>>>>>>>>>>> [2]
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>g
>>>>>>>>>>>>> ith
>>>>>>>>>>> u
>>>>>>>>>>>>> b.c
>>>>>>>>>>>>> om%2Fapache%2Froyale-
>>>>>>>>>>> asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs&data=02
>>>>>>>>>>>>> %7C
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2
>>>>>>>>>>c
>>>>>>>>>>>>> 178
>>>>>>>>>>> d
>>>>>>>>>>>>> ece
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR6M
>>>>>>>>>>D
>>>>>>>>>>>>> c%2
>>>>>>>>>>> B
>>>>>>>>>>>>> t1Y
>>>>>>>>>>>>> YMHGPVL7jA%3D&reserved=0
>>>>>>>>>>>>> [3]
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>g
>>>>>>>>>>>>> ith
>>>>>>>>>>> u
>>>>>>>>>>>>> b.c
>>>>>>>>>>>>> om%2Fapache%2Froyale-
>>>>>>>>>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>>>>>>>>>>>> 88%
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&s
>>>>>>>>>>d
>>>>>>>>>>>>> ata
>>>>>>>>>>> =
>>>>>>>>>>>>> xB2
>>>>>>>>>>>>> 5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apa
>>>>>>>>>>c
>>>>>>>>>>>>> he/
>>>>>>>>>>> f
>>>>>>>>>>>>> l
>>>>>>>>>>>>> ex/html
>>>>>>>>>>>>> [4]
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>c
>>>>>>>>>>>>> wik
>>>>>>>>>>> i
>>>>>>>>>>>>> .ap
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%
>>>>>>>>>>3
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796478
>>>>>>>>>>8
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&
>>>>>>>>>>s
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>
>>>>>>>>>>%
>>>>>>>>>>>>> 2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat
>>>>>>>>>>> a
>>>>>>>>>>>>> =02
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794a
>>>>>>>>>>e
>>>>>>>>>>>>> d2c
>>>>>>>>>>> 1
>>>>>>>>>>>>> 78d
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7a8
>>>>>>>>>>l
>>>>>>>>>>>>> QTz
>>>>>>>>>>> L
>>>>>>>>>>>>> 8KG
>>>>>>>>>>>>> N7kM0uCu2z4%3D&reserved=0
>>>>>>>>>>>>> 28
>>>>>>>>>>>>> [5]
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>g
>>>>>>>>>>>>> ith
>>>>>>>>>>> u
>>>>>>>>>>>>> b.c
>>>>>>>>>>>>> om%2Fapache%2Froyale-
>>>>>>>>>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>>>>>>>>>>>> 88%
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&s
>>>>>>>>>>d
>>>>>>>>>>>>> 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%2F
>>>>>>>>>>g
>>>>>>>>>>>>> ith
>>>>>>>>>>> u
>>>>>>>>>>>>> b.c
>>>>>>>>>>>>> om%2Fapache%2Froyale-
>>>>>>>>>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>>>>>>>>>>>> 88%
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&s
>>>>>>>>>>d
>>>>>>>>>>>>> ata
>>>>>>>>>>> =
>>>>>>>>>>>>> xB2
>>>>>>>>>>>>> 5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>>>>>>>>>>>>> asjs/tree/develop/examples/flexjs/MDLExample
>>>>>>>>>>>>> [7]
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>g
>>>>>>>>>>>>> etm
>>>>>>>>>>> d
>>>>>>>>>>>>> l.i
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>o%2Fcomponents%2Findex.html&data=02%7C01%7C%7Cab4e20a981d44a9ea01
>>>>>>>>>>4
>>>>>>>>>>>>> 08d
>>>>>>>>>>> 5
>>>>>>>>>>>>> 06a
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642224594218
>>>>>>>>>>3
>>>>>>>>>>>>> 624
>>>>>>>>>>> &
>>>>>>>>>>>>> sda
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ta=U6IQ%2Fikcn61Row6PjP%2FLF%2F4kqle2pe4U%2BEgAuxMfL90%3D&reserve
>>>>>>>>>>d
>>>>>>>>>>>>> =0
>>>>>>>>>>>>> [8]
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>c
>>>>>>>>>>>>> wik
>>>>>>>>>>> i
>>>>>>>>>>>>> .ap
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%
>>>>>>>>>>3
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796478
>>>>>>>>>>8
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&
>>>>>>>>>>s
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>
>>>>>>>>>>%
>>>>>>>>>>>>> 2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data
>>>>>>>>>>> =
>>>>>>>>>>>>> 02%
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794ae
>>>>>>>>>>d
>>>>>>>>>>>>> 2c1
>>>>>>>>>>> 7
>>>>>>>>>>>>> 8de
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xRtJ
>>>>>>>>>>r
>>>>>>>>>>>>> dXn
>>>>>>>>>>> D
>>>>>>>>>>>>> Lai
>>>>>>>>>>>>> 3UM8LpiO7APc%3D&reserved=0
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks, Piotr
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2017-09-28 17:58 GMT+02:00 Idylog - Nicolas Granon
>>>>>>>>>>>>> <ng...@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%2F
>>>>>>>>>>c
>>>>>>>>>>>>> wik
>>>>>>>>>>> i
>>>>>>>>>>>>> .ap
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%
>>>>>>>>>>3
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796478
>>>>>>>>>>8
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&
>>>>>>>>>>s
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>
>>>>>>>>>>%
>>>>>>>>>>>>> 2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0
>>>>>>>>>>> 2
>>>>>>>>>>>>> %7C
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2
>>>>>>>>>>c
>>>>>>>>>>>>> 178
>>>>>>>>>>> d
>>>>>>>>>>>>> ece
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoLzL
>>>>>>>>>>H
>>>>>>>>>>>>> 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%2Fw
>>>>>>>>>>w
>>>>>>>>>>>>> w.l
>>>>>>>>>>> i
>>>>>>>>>>>>> nke
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>din.com<https://na01.safelinks.protection.outlook.com/?url=http%3
>>>>>>>>>>A
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%2F%2Fdin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788%
>>>>>>>>>>7
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&sd
>>>>>>>>>>a
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>ta=B7M%2BhYPAUN%2FwIEe4DoMPpIjTZhxpwoTlKNrD%2FZaqkAg%3D&reserved=
>>>>>>>>>>0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>%2Fpiotrzarzycki&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506
>>>>>>>>>>>>>>a
>>>>>>>>>>> 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%2
>>>>>>>>>>F
>>>>>>>>>>pl.
>>>>>>>>>>> l
>>>>>>>>>>>>> ink
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>edin.com<https://na01.safelinks.protection.outlook.com/?url=http%
>>>>>>>>>>3
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>A%2F%2Fedin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796478
>>>>>>>>>>8
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>%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%7C63
>>>>>>>>>>6
>>>>>>>>>>>>> 422
>>>>>>>>>>> 2
>>>>>>>>>>>>> 459
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>42183624&sdata=tSGDWZ5AhBPECbf1%2Fy9R2u9N4qwJ03VBhzwzNsPTcCM%3D&r
>>>>>>>>>>e
>>>>>>>>>>>>> ser
>>>>>>>>>>> v
>>>>>>>>>>>>> ed=
>>>>>>>>>>>>> 0>
>>>>>>>>>>>>>
>>>>>>>>>>>>> GitHub:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>>>>>g
>>>>>>>>>>>>> ith
>>>>>>>>>>> u
>>>>>>>>>>>>> b.c
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>om%2Fpiotrzarzycki21&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506
>>>>>>>>>>a
>>>>>>>>>>>>> 926
>>>>>>>>>>> 8
>>>>>>>>>>>>> 8%7
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sd
>>>>>>>>>>a
>>>>>>>>>>>>> ta=
>>>>>>>>>>> l
>>>>>>>>>>>>> Mum
>>>>>>>>>>>>> yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Sounds worth a try. Note that Royale ASDoc is currently a Royale app.
Also note that regular Flex used [Alternative] metadata to point from MX
components to Spark components. I think we want the opposite, though, and
point from Royale components back to MX and Spark components.
I believe that any new asdoc tags or metadata goes in the JSON files used
by the Royale ASDoc app so data should be easy to create.
HTH,
-Alex
On 10/3/17, 1:33 PM, "Harbs" <ha...@gmail.com> wrote:
>Hmm. Thinking about it some more, I’m thinking that a Royale app to
>display the data could be a very good idea. It could solve the real
>estate problem and make finding options very easy.
>
>Basically, you could either browse for search for a mx or spark component
>and you could then get a picker for all the component sets which have a
>match. As we build out our component sets there could be multiple matches
>or alternates.
>
>We’d have to come up with a data format for finding references to
>matching or alternative components. Ideally this would be info that’s
>pulled from the ASDoc output.
>
>Thoughts?
>
>> On Oct 3, 2017, at 11:22 PM, Harbs <ha...@gmail.com> wrote:
>>
>> GH Pages is likely the way to go. Maybe we could make the comparison an
>>interactive Royale app… ;-)
>>
>>> On Oct 3, 2017, at 11:18 PM, Alex Harui <ah...@adobe.com> wrote:
>>>
>>> OK, maybe wait until royale-docs is up and try GH Pages? Or if it is
>>> better as plain HTML, put it on royale.a.o?
>>>
>>> -Alex
>>>
>>> On 10/3/17, 1:13 PM, "Harbs" <ha...@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 <pe...@adobe.com> wrote:
>>>>>
>>>>> I have a quick sample web page up at:
>>>>>
>>>>>
>>>>>
>>>>>https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fhome.apa
>>>>>che
>>>>>
>>>>>.org%2F~pent%2FFlex2Royale%2F&data=02%7C01%7C%7C8a812742e9fc437f944508
>>>>>d50
>>>>>
>>>>>a9b42ed%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642658431317237
>>>>>3&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" <ng...@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
>>>>>>> <pi...@gmail.com>>
>>>>>>> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>>>> <us...@royale.apache.org>>
>>>>>>> Date: Friday, September 29, 2017 at 5:00 PM
>>>>>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>>>> <us...@royale.apache.org>>,
>>>>>>> "users@flex.apache.org<ma...@flex.apache.org>"
>>>>>>> <us...@flex.apache.org>>,
>>>>>>> "ngranon@idylog.com<ma...@idylog.com>"
>>>>>>> <ng...@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
>>>>>>> <ah...@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"
>>>>>>> <pe...@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"
>>>>>>> <ng...@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<ma...@adobe.com.INVALID>
>>>>>>>>>>]
>>>>>>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>>>>>>>>>> users@flex.apache.org<ma...@flex.apache.org>;
>>>>>>>>>> ngranon@idylog.com<ma...@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"
>>>>>>>>>> <ng...@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<ma...@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
>>>>>>>>>>>> <ng...@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%2F
>>>>>>>>>pl.
>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
RE: [Royale] Flex to FlexJS migration path
Posted by Idylog - Nicolas Granon <ng...@idylog.com>.
That is a great idea !
That would allow to hide/show columns and (partially) solve the real-estate issue.
It would also be a great "live example" (maybe the source code could be made public ?)
Nicolas Granon
> -----Message d'origine-----
> De : Harbs [mailto:harbs.lists@gmail.com]
> Envoyé : mardi 3 octobre 2017 22:33
> À : users@royale.apache.org
> Cc : dev@royale.apache.org; users@flex.apache.org
> Objet : Re: [Royale] Flex to FlexJS migration path
>
> Hmm. Thinking about it some more, I’m thinking that a Royale app to
> display the data could be a very good idea. It could solve the real
> estate problem and make finding options very easy.
>
> Basically, you could either browse for search for a mx or spark
> component and you could then get a picker for all the component sets
> which have a match. As we build out our component sets there could be
> multiple matches or alternates.
>
> We’d have to come up with a data format for finding references to
> matching or alternative components. Ideally this would be info that’s
> pulled from the ASDoc output.
>
> Thoughts?
>
> > On Oct 3, 2017, at 11:22 PM, Harbs <ha...@gmail.com> wrote:
> >
> > GH Pages is likely the way to go. Maybe we could make the comparison
> > an interactive Royale app… ;-)
> >
> >> On Oct 3, 2017, at 11:18 PM, Alex Harui <ah...@adobe.com> wrote:
> >>
> >> OK, maybe wait until royale-docs is up and try GH Pages? Or if it
> is
> >> better as plain HTML, put it on royale.a.o?
> >>
> >> -Alex
> >>
> >> On 10/3/17, 1:13 PM, "Harbs" <ha...@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 <pe...@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%7C8a812742e9fc437f944
> >>>> 508d50
> >>>>
> a9b42ed%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642658431317
> >>>> 2373&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"
> <ng...@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
> >>>>>> <pi...@gmail.com>>
> >>>>>> Reply-To:
> "users@royale.apache.org<ma...@royale.apache.org>"
> >>>>>> <us...@royale.apache.org>>
> >>>>>> Date: Friday, September 29, 2017 at 5:00 PM
> >>>>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
> >>>>>> <us...@royale.apache.org>>,
> >>>>>> "users@flex.apache.org<ma...@flex.apache.org>"
> >>>>>> <us...@flex.apache.org>>,
> >>>>>> "ngranon@idylog.com<ma...@idylog.com>"
> >>>>>> <ng...@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
> >>>>>> <ah...@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"
> >>>>>> <pe...@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"
> >>>>>> <ng...@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.INVAL
> >>>>>>>>> ID>] Envoyé : jeudi 28 septembre 2017 22:32 À :
> >>>>>>>>> users@flex.apache.org<ma...@flex.apache.org>;
> >>>>>>>>> ngranon@idylog.com<ma...@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"
> >>>>>>>>> <ng...@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<ma...@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=htt
> >>>>>>>> p%3
> >>>>>>>>>
> >>>>>>>>
> A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964
> >>>>>>>> 788
> >>>>>>>>>
> >>>>>>>>
> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642326439203225
> >>>>>>>> 6&s
> >>>>>>>>>
> >>>>>>>>
> data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=
> >>>>>>>> 0>%
> >>>>>>>>>>>
> 2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d
> >>>>>>>>> a
> >>>>>>>>>>> ta=
> >>>>>>>>>
> >>>>>>>>
> 02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438
> >>>>>>>> 794
> >>>>>>>>>>> aed
> >>>>>>>>> 2
> >>>>>>>>>>> c17
> >>>>>>>>>
> >>>>>>>>
> 8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3
> >>>>>>>> Xru
> >>>>>>>>>>> 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%7Cfa7b1b5a7b34438794ae
> >>>>>>>> d2c
> >>>>>>>>>>> 178
> >>>>>>>>> d
> >>>>>>>>>>> ece
> >>>>>>>>>
> >>>>>>>>
> e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR
> >>>>>>>> 6MD
> >>>>>>>>>>> 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/a
> >>>>>>>> pac
> >>>>>>>>>>> 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=htt
> >>>>>>>> p%3
> >>>>>>>>>
> >>>>>>>>
> A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964
> >>>>>>>> 788
> >>>>>>>>>
> >>>>>>>>
> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642326439203225
> >>>>>>>> 6&s
> >>>>>>>>>
> >>>>>>>>
> data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=
> >>>>>>>> 0>%
> >>>>>>>>>>>
> 2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat
> >>>>>>>>> a
> >>>>>>>>>>> =02
> >>>>>>>>>
> >>>>>>>>
> %7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b3443879
> >>>>>>>> 4ae
> >>>>>>>>>>> d2c
> >>>>>>>>> 1
> >>>>>>>>>>> 78d
> >>>>>>>>>
> >>>>>>>>
> ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7
> >>>>>>>> a8l
> >>>>>>>>>>> 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/ma
> >>>>>>>> in/
> >>>>>>>>>>> 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%7Cab4e20a981d44a9ea
> >>>>>>>> 014
> >>>>>>>>>>> 08d
> >>>>>>>>> 5
> >>>>>>>>>>> 06a
> >>>>>>>>>
> >>>>>>>>
> 92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942
> >>>>>>>> 183
> >>>>>>>>>>> 624
> >>>>>>>>> &
> >>>>>>>>>>> sda
> >>>>>>>>>
> >>>>>>>>
> ta=U6IQ%2Fikcn61Row6PjP%2FLF%2F4kqle2pe4U%2BEgAuxMfL90%3D&reser
> >>>>>>>> ved
> >>>>>>>>>>> =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=htt
> >>>>>>>> p%3
> >>>>>>>>>
> >>>>>>>>
> A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964
> >>>>>>>> 788
> >>>>>>>>>
> >>>>>>>>
> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642326439203225
> >>>>>>>> 6&s
> >>>>>>>>>
> >>>>>>>>
> data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=
> >>>>>>>> 0>%
> >>>>>>>>>>>
> 2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data
> >>>>>>>>> =
> >>>>>>>>>>> 02%
> >>>>>>>>>
> >>>>>>>>
> 7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794
> >>>>>>>> aed
> >>>>>>>>>>> 2c1
> >>>>>>>>> 7
> >>>>>>>>>>> 8de
> >>>>>>>>>
> >>>>>>>>
> cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xR
> >>>>>>>> tJr
> >>>>>>>>>>> dXn
> >>>>>>>>> D
> >>>>>>>>>>> Lai
> >>>>>>>>>>> 3UM8LpiO7APc%3D&reserved=0
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks, Piotr
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> 2017-09-28 17:58 GMT+02:00 Idylog - Nicolas Granon
> >>>>>>>>>>> <ng...@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=htt
> >>>>>>>> p%3
> >>>>>>>>>
> >>>>>>>>
> A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964
> >>>>>>>> 788
> >>>>>>>>>
> >>>>>>>>
> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642326439203225
> >>>>>>>> 6&s
> >>>>>>>>>
> >>>>>>>>
> data=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=
> >>>>>>>> 0>%
> >>>>>>>>>>>
> 2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0
> >>>>>>>>> 2
> >>>>>>>>>>> %7C
> >>>>>>>>>
> >>>>>>>>
> 01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794ae
> >>>>>>>> d2c
> >>>>>>>>>>> 178
> >>>>>>>>> d
> >>>>>>>>>>> ece
> >>>>>>>>>
> >>>>>>>>
> e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoL
> >>>>>>>> zLH
> >>>>>>>>>>> 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%2
> >>>>>>>> Fww
> >>>>>>>>>>> w.l
> >>>>>>>>> i
> >>>>>>>>>>> nke
> >>>>>>>>>
> >>>>>>>>
> din.com<https://na01.safelinks.protection.outlook.com/?url=http
> >>>>>>>> %3A
> >>>>>>>>>
> >>>>>>>>
> %2F%2Fdin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d50796478
> >>>>>>>> 8%7
> >>>>>>>>>
> >>>>>>>>
> Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&
> >>>>>>>> sda
> >>>>>>>>>
> >>>>>>>>
> ta=B7M%2BhYPAUN%2FwIEe4DoMPpIjTZhxpwoTlKNrD%2FZaqkAg%3D&reserve
> >>>>>>>> d=0
> >>>>>>>>>>>>
> %2Fpiotrzarzycki&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d5
> >>>>>>>>>>>> 06a
> >>>>>>>>> 9
> >>>>>>>>>>> 268
> >>>>>>>>>
> >>>>>>>>
> 8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364222459421836
> >>>>>>>> 24&
> >>>>>>>>>>> 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=htt
> >>>>>>>> p%3
> >>>>>>>>>
> >>>>>>>>
> A%2F%2Fedin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964
> >>>>>>>> 788
> >>>>>>>>>
> >>>>>>>>
> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642326439203225
> >>>>>>>> 6&s
> >>>>>>>>>
> >>>>>>>>
> data=7rUvU4thZJ3Ja1S4aMg4RwxKGwoMgN4%2FIZ4RY9W4MwE%3D&reserved=
> >>>>>>>> 0>%
> >>>>>>>>>>> 2Fin%2Fpiotr-zarzycki-
> >>>>>>>>> 92a53552&data=02%7C01%7C%7Cab4e20a981d4
> >>>>>>>>>>> 4a9
> >>>>>>>>>
> >>>>>>>>
> ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C
> >>>>>>>> 636
> >>>>>>>>>>> 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%7Cab4e20a981d44a9ea01408d5
> >>>>>>>> 06a
> >>>>>>>>>>> 926
> >>>>>>>>> 8
> >>>>>>>>>>> 8%7
> >>>>>>>>>
> >>>>>>>>
> Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&
> >>>>>>>> sda
> >>>>>>>>>>> ta=
> >>>>>>>>> l
> >>>>>>>>>>> Mum
> >>>>>>>>>>> yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
Re: [Royale] Flex to FlexJS migration path
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Sounds worth a try. Note that Royale ASDoc is currently a Royale app.
Also note that regular Flex used [Alternative] metadata to point from MX
components to Spark components. I think we want the opposite, though, and
point from Royale components back to MX and Spark components.
I believe that any new asdoc tags or metadata goes in the JSON files used
by the Royale ASDoc app so data should be easy to create.
HTH,
-Alex
On 10/3/17, 1:33 PM, "Harbs" <ha...@gmail.com> wrote:
>Hmm. Thinking about it some more, I’m thinking that a Royale app to
>display the data could be a very good idea. It could solve the real
>estate problem and make finding options very easy.
>
>Basically, you could either browse for search for a mx or spark component
>and you could then get a picker for all the component sets which have a
>match. As we build out our component sets there could be multiple matches
>or alternates.
>
>We’d have to come up with a data format for finding references to
>matching or alternative components. Ideally this would be info that’s
>pulled from the ASDoc output.
>
>Thoughts?
>
>> On Oct 3, 2017, at 11:22 PM, Harbs <ha...@gmail.com> wrote:
>>
>> GH Pages is likely the way to go. Maybe we could make the comparison an
>>interactive Royale app… ;-)
>>
>>> On Oct 3, 2017, at 11:18 PM, Alex Harui <ah...@adobe.com> wrote:
>>>
>>> OK, maybe wait until royale-docs is up and try GH Pages? Or if it is
>>> better as plain HTML, put it on royale.a.o?
>>>
>>> -Alex
>>>
>>> On 10/3/17, 1:13 PM, "Harbs" <ha...@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 <pe...@adobe.com> wrote:
>>>>>
>>>>> I have a quick sample web page up at:
>>>>>
>>>>>
>>>>>
>>>>>https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fhome.apa
>>>>>che
>>>>>
>>>>>.org%2F~pent%2FFlex2Royale%2F&data=02%7C01%7C%7C8a812742e9fc437f944508
>>>>>d50
>>>>>
>>>>>a9b42ed%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642658431317237
>>>>>3&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" <ng...@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
>>>>>>> <pi...@gmail.com>>
>>>>>>> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>>>> <us...@royale.apache.org>>
>>>>>>> Date: Friday, September 29, 2017 at 5:00 PM
>>>>>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>>>> <us...@royale.apache.org>>,
>>>>>>> "users@flex.apache.org<ma...@flex.apache.org>"
>>>>>>> <us...@flex.apache.org>>,
>>>>>>> "ngranon@idylog.com<ma...@idylog.com>"
>>>>>>> <ng...@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
>>>>>>> <ah...@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"
>>>>>>> <pe...@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"
>>>>>>> <ng...@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<ma...@adobe.com.INVALID>
>>>>>>>>>>]
>>>>>>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>>>>>>>>>> users@flex.apache.org<ma...@flex.apache.org>;
>>>>>>>>>> ngranon@idylog.com<ma...@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"
>>>>>>>>>> <ng...@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<ma...@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
>>>>>>>>>>>> <ng...@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%2F
>>>>>>>>>pl.
>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Alex Harui <ah...@adobe.com>.
Sounds worth a try. Note that Royale ASDoc is currently a Royale app.
Also note that regular Flex used [Alternative] metadata to point from MX
components to Spark components. I think we want the opposite, though, and
point from Royale components back to MX and Spark components.
I believe that any new asdoc tags or metadata goes in the JSON files used
by the Royale ASDoc app so data should be easy to create.
HTH,
-Alex
On 10/3/17, 1:33 PM, "Harbs" <ha...@gmail.com> wrote:
>Hmm. Thinking about it some more, I’m thinking that a Royale app to
>display the data could be a very good idea. It could solve the real
>estate problem and make finding options very easy.
>
>Basically, you could either browse for search for a mx or spark component
>and you could then get a picker for all the component sets which have a
>match. As we build out our component sets there could be multiple matches
>or alternates.
>
>We’d have to come up with a data format for finding references to
>matching or alternative components. Ideally this would be info that’s
>pulled from the ASDoc output.
>
>Thoughts?
>
>> On Oct 3, 2017, at 11:22 PM, Harbs <ha...@gmail.com> wrote:
>>
>> GH Pages is likely the way to go. Maybe we could make the comparison an
>>interactive Royale app… ;-)
>>
>>> On Oct 3, 2017, at 11:18 PM, Alex Harui <ah...@adobe.com> wrote:
>>>
>>> OK, maybe wait until royale-docs is up and try GH Pages? Or if it is
>>> better as plain HTML, put it on royale.a.o?
>>>
>>> -Alex
>>>
>>> On 10/3/17, 1:13 PM, "Harbs" <ha...@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 <pe...@adobe.com> wrote:
>>>>>
>>>>> I have a quick sample web page up at:
>>>>>
>>>>>
>>>>>
>>>>>https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fhome.apa
>>>>>che
>>>>>
>>>>>.org%2F~pent%2FFlex2Royale%2F&data=02%7C01%7C%7C8a812742e9fc437f944508
>>>>>d50
>>>>>
>>>>>a9b42ed%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642658431317237
>>>>>3&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" <ng...@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
>>>>>>> <pi...@gmail.com>>
>>>>>>> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>>>> <us...@royale.apache.org>>
>>>>>>> Date: Friday, September 29, 2017 at 5:00 PM
>>>>>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>>>> <us...@royale.apache.org>>,
>>>>>>> "users@flex.apache.org<ma...@flex.apache.org>"
>>>>>>> <us...@flex.apache.org>>,
>>>>>>> "ngranon@idylog.com<ma...@idylog.com>"
>>>>>>> <ng...@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
>>>>>>> <ah...@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"
>>>>>>> <pe...@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"
>>>>>>> <ng...@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<ma...@adobe.com.INVALID>
>>>>>>>>>>]
>>>>>>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>>>>>>>>>> users@flex.apache.org<ma...@flex.apache.org>;
>>>>>>>>>> ngranon@idylog.com<ma...@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"
>>>>>>>>>> <ng...@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<ma...@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
>>>>>>>>>>>> <ng...@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%2F
>>>>>>>>>pl.
>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Harbs <ha...@gmail.com>.
Hmm. Thinking about it some more, I’m thinking that a Royale app to display the data could be a very good idea. It could solve the real estate problem and make finding options very easy.
Basically, you could either browse for search for a mx or spark component and you could then get a picker for all the component sets which have a match. As we build out our component sets there could be multiple matches or alternates.
We’d have to come up with a data format for finding references to matching or alternative components. Ideally this would be info that’s pulled from the ASDoc output.
Thoughts?
> On Oct 3, 2017, at 11:22 PM, Harbs <ha...@gmail.com> wrote:
>
> GH Pages is likely the way to go. Maybe we could make the comparison an interactive Royale app… ;-)
>
>> On Oct 3, 2017, at 11:18 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>> OK, maybe wait until royale-docs is up and try GH Pages? Or if it is
>> better as plain HTML, put it on royale.a.o?
>>
>> -Alex
>>
>> On 10/3/17, 1:13 PM, "Harbs" <ha...@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 <pe...@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" <ng...@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
>>>>>> <pi...@gmail.com>>
>>>>>> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>>> <us...@royale.apache.org>>
>>>>>> Date: Friday, September 29, 2017 at 5:00 PM
>>>>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>>> <us...@royale.apache.org>>,
>>>>>> "users@flex.apache.org<ma...@flex.apache.org>"
>>>>>> <us...@flex.apache.org>>,
>>>>>> "ngranon@idylog.com<ma...@idylog.com>"
>>>>>> <ng...@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
>>>>>> <ah...@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"
>>>>>> <pe...@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"
>>>>>> <ng...@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<ma...@adobe.com.INVALID>]
>>>>>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>>>>>>>>> users@flex.apache.org<ma...@flex.apache.org>;
>>>>>>>>> ngranon@idylog.com<ma...@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"
>>>>>>>>> <ng...@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<ma...@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
>>>>>>>>>>> <ng...@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
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Harbs <ha...@gmail.com>.
Hmm. Thinking about it some more, I’m thinking that a Royale app to display the data could be a very good idea. It could solve the real estate problem and make finding options very easy.
Basically, you could either browse for search for a mx or spark component and you could then get a picker for all the component sets which have a match. As we build out our component sets there could be multiple matches or alternates.
We’d have to come up with a data format for finding references to matching or alternative components. Ideally this would be info that’s pulled from the ASDoc output.
Thoughts?
> On Oct 3, 2017, at 11:22 PM, Harbs <ha...@gmail.com> wrote:
>
> GH Pages is likely the way to go. Maybe we could make the comparison an interactive Royale app… ;-)
>
>> On Oct 3, 2017, at 11:18 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>> OK, maybe wait until royale-docs is up and try GH Pages? Or if it is
>> better as plain HTML, put it on royale.a.o?
>>
>> -Alex
>>
>> On 10/3/17, 1:13 PM, "Harbs" <ha...@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 <pe...@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" <ng...@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
>>>>>> <pi...@gmail.com>>
>>>>>> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>>> <us...@royale.apache.org>>
>>>>>> Date: Friday, September 29, 2017 at 5:00 PM
>>>>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>>> <us...@royale.apache.org>>,
>>>>>> "users@flex.apache.org<ma...@flex.apache.org>"
>>>>>> <us...@flex.apache.org>>,
>>>>>> "ngranon@idylog.com<ma...@idylog.com>"
>>>>>> <ng...@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
>>>>>> <ah...@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"
>>>>>> <pe...@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"
>>>>>> <ng...@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<ma...@adobe.com.INVALID>]
>>>>>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>>>>>>>>> users@flex.apache.org<ma...@flex.apache.org>;
>>>>>>>>> ngranon@idylog.com<ma...@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"
>>>>>>>>> <ng...@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<ma...@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
>>>>>>>>>>> <ng...@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
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Harbs <ha...@gmail.com>.
Hmm. Thinking about it some more, I’m thinking that a Royale app to display the data could be a very good idea. It could solve the real estate problem and make finding options very easy.
Basically, you could either browse for search for a mx or spark component and you could then get a picker for all the component sets which have a match. As we build out our component sets there could be multiple matches or alternates.
We’d have to come up with a data format for finding references to matching or alternative components. Ideally this would be info that’s pulled from the ASDoc output.
Thoughts?
> On Oct 3, 2017, at 11:22 PM, Harbs <ha...@gmail.com> wrote:
>
> GH Pages is likely the way to go. Maybe we could make the comparison an interactive Royale app… ;-)
>
>> On Oct 3, 2017, at 11:18 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>> OK, maybe wait until royale-docs is up and try GH Pages? Or if it is
>> better as plain HTML, put it on royale.a.o?
>>
>> -Alex
>>
>> On 10/3/17, 1:13 PM, "Harbs" <ha...@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 <pe...@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" <ng...@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
>>>>>> <pi...@gmail.com>>
>>>>>> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>>> <us...@royale.apache.org>>
>>>>>> Date: Friday, September 29, 2017 at 5:00 PM
>>>>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>>> <us...@royale.apache.org>>,
>>>>>> "users@flex.apache.org<ma...@flex.apache.org>"
>>>>>> <us...@flex.apache.org>>,
>>>>>> "ngranon@idylog.com<ma...@idylog.com>"
>>>>>> <ng...@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
>>>>>> <ah...@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"
>>>>>> <pe...@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"
>>>>>> <ng...@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<ma...@adobe.com.INVALID>]
>>>>>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>>>>>>>>> users@flex.apache.org<ma...@flex.apache.org>;
>>>>>>>>> ngranon@idylog.com<ma...@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"
>>>>>>>>> <ng...@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<ma...@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
>>>>>>>>>>> <ng...@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
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Harbs <ha...@gmail.com>.
GH Pages is likely the way to go. Maybe we could make the comparison an interactive Royale app… ;-)
> On Oct 3, 2017, at 11:18 PM, Alex Harui <ah...@adobe.com> wrote:
>
> OK, maybe wait until royale-docs is up and try GH Pages? Or if it is
> better as plain HTML, put it on royale.a.o?
>
> -Alex
>
> On 10/3/17, 1:13 PM, "Harbs" <ha...@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 <pe...@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" <ng...@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
>>>>> <pi...@gmail.com>>
>>>>> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>> <us...@royale.apache.org>>
>>>>> Date: Friday, September 29, 2017 at 5:00 PM
>>>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>> <us...@royale.apache.org>>,
>>>>> "users@flex.apache.org<ma...@flex.apache.org>"
>>>>> <us...@flex.apache.org>>,
>>>>> "ngranon@idylog.com<ma...@idylog.com>"
>>>>> <ng...@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
>>>>> <ah...@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"
>>>>> <pe...@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"
>>>>> <ng...@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<ma...@adobe.com.INVALID>]
>>>>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>>>>>>>> users@flex.apache.org<ma...@flex.apache.org>;
>>>>>>>> ngranon@idylog.com<ma...@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"
>>>>>>>> <ng...@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<ma...@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
>>>>>>>>>> <ng...@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
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Harbs <ha...@gmail.com>.
GH Pages is likely the way to go. Maybe we could make the comparison an interactive Royale app… ;-)
> On Oct 3, 2017, at 11:18 PM, Alex Harui <ah...@adobe.com> wrote:
>
> OK, maybe wait until royale-docs is up and try GH Pages? Or if it is
> better as plain HTML, put it on royale.a.o?
>
> -Alex
>
> On 10/3/17, 1:13 PM, "Harbs" <ha...@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 <pe...@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" <ng...@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
>>>>> <pi...@gmail.com>>
>>>>> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>> <us...@royale.apache.org>>
>>>>> Date: Friday, September 29, 2017 at 5:00 PM
>>>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>>> <us...@royale.apache.org>>,
>>>>> "users@flex.apache.org<ma...@flex.apache.org>"
>>>>> <us...@flex.apache.org>>,
>>>>> "ngranon@idylog.com<ma...@idylog.com>"
>>>>> <ng...@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
>>>>> <ah...@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"
>>>>> <pe...@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"
>>>>> <ng...@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<ma...@adobe.com.INVALID>]
>>>>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>>>>>>>> users@flex.apache.org<ma...@flex.apache.org>;
>>>>>>>> ngranon@idylog.com<ma...@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"
>>>>>>>> <ng...@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<ma...@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
>>>>>>>>>> <ng...@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
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Alex Harui <ah...@adobe.com>.
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" <ha...@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 <pe...@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" <ng...@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
>>>> <pi...@gmail.com>>
>>>> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>> <us...@royale.apache.org>>
>>>> Date: Friday, September 29, 2017 at 5:00 PM
>>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>> <us...@royale.apache.org>>,
>>>> "users@flex.apache.org<ma...@flex.apache.org>"
>>>> <us...@flex.apache.org>>,
>>>> "ngranon@idylog.com<ma...@idylog.com>"
>>>> <ng...@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
>>>> <ah...@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"
>>>> <pe...@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"
>>>> <ng...@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<ma...@adobe.com.INVALID>]
>>>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>>>>>>> users@flex.apache.org<ma...@flex.apache.org>;
>>>>>>> ngranon@idylog.com<ma...@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"
>>>>>>> <ng...@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<ma...@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
>>>>>>>>> <ng...@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
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@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 <pe...@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" <ng...@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
>>>> <pi...@gmail.com>>
>>>> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>> <us...@royale.apache.org>>
>>>> Date: Friday, September 29, 2017 at 5:00 PM
>>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>>>> <us...@royale.apache.org>>,
>>>> "users@flex.apache.org<ma...@flex.apache.org>"
>>>> <us...@flex.apache.org>>,
>>>> "ngranon@idylog.com<ma...@idylog.com>"
>>>> <ng...@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
>>>> <ah...@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"
>>>> <pe...@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"
>>>> <ng...@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<ma...@adobe.com.INVALID>]
>>>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>>>>>>> users@flex.apache.org<ma...@flex.apache.org>;
>>>>>>> ngranon@idylog.com<ma...@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"
>>>>>>> <ng...@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<ma...@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
>>>>>>>>> <ng...@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
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Harbs <ha...@gmail.com>.
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 <pe...@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" <ng...@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
>>> <pi...@gmail.com>>
>>> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
>>> <us...@royale.apache.org>>
>>> Date: Friday, September 29, 2017 at 5:00 PM
>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>>> <us...@royale.apache.org>>,
>>> "users@flex.apache.org<ma...@flex.apache.org>"
>>> <us...@flex.apache.org>>,
>>> "ngranon@idylog.com<ma...@idylog.com>"
>>> <ng...@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
>>> <ah...@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"
>>> <pe...@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"
>>> <ng...@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<ma...@adobe.com.INVALID>]
>>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>>>>>> users@flex.apache.org<ma...@flex.apache.org>;
>>>>>> ngranon@idylog.com<ma...@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"
>>>>>> <ng...@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<ma...@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
>>>>>>>> <ng...@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
>>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Harbs <ha...@gmail.com>.
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 <pe...@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" <ng...@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
>>> <pi...@gmail.com>>
>>> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
>>> <us...@royale.apache.org>>
>>> Date: Friday, September 29, 2017 at 5:00 PM
>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>>> <us...@royale.apache.org>>,
>>> "users@flex.apache.org<ma...@flex.apache.org>"
>>> <us...@flex.apache.org>>,
>>> "ngranon@idylog.com<ma...@idylog.com>"
>>> <ng...@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
>>> <ah...@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"
>>> <pe...@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"
>>> <ng...@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<ma...@adobe.com.INVALID>]
>>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>>>>>> users@flex.apache.org<ma...@flex.apache.org>;
>>>>>> ngranon@idylog.com<ma...@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"
>>>>>> <ng...@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<ma...@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
>>>>>>>> <ng...@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
>>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Mark Kessler <ke...@gmail.com>.
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 <pe...@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" <ng...@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
>>> <pi...@gmail.com>>
>>> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
>>> <us...@royale.apache.org>>
>>> Date: Friday, September 29, 2017 at 5:00 PM
>>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>>> <us...@royale.apache.org>>,
>>> "users@flex.apache.org<ma...@flex.apache.org>"
>>> <us...@flex.apache.org>>,
>>> "ngranon@idylog.com<ma...@idylog.com>"
>>> <ng...@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
>>> <ah...@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"
>>> <pe...@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"
>>> <ng...@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<ma...@adobe.com.INVALID>]
>>> >>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>>> >>> users@flex.apache.org<ma...@flex.apache.org>;
>>> >>> ngranon@idylog.com<ma...@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"
>>> >>> <ng...@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<ma...@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
>>> >>> >> <ng...@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
>>> >>> >
>>> >>
>>> >>
>>> >
>>
>>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Peter Ent <pe...@adobe.com.INVALID>.
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" <ng...@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
>> <pi...@gmail.com>>
>> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
>> <us...@royale.apache.org>>
>> Date: Friday, September 29, 2017 at 5:00 PM
>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>> <us...@royale.apache.org>>,
>> "users@flex.apache.org<ma...@flex.apache.org>"
>> <us...@flex.apache.org>>,
>> "ngranon@idylog.com<ma...@idylog.com>"
>> <ng...@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
>> <ah...@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"
>> <pe...@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"
>> <ng...@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<ma...@adobe.com.INVALID>]
>> >>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>> >>> users@flex.apache.org<ma...@flex.apache.org>;
>> >>> ngranon@idylog.com<ma...@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"
>> >>> <ng...@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<ma...@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
>> >>> >> <ng...@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
>> >>> >
>> >>
>> >>
>> >
>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Peter Ent <pe...@adobe.com>.
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" <ng...@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
>> <pi...@gmail.com>>
>> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
>> <us...@royale.apache.org>>
>> Date: Friday, September 29, 2017 at 5:00 PM
>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>> <us...@royale.apache.org>>,
>> "users@flex.apache.org<ma...@flex.apache.org>"
>> <us...@flex.apache.org>>,
>> "ngranon@idylog.com<ma...@idylog.com>"
>> <ng...@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
>> <ah...@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"
>> <pe...@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"
>> <ng...@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<ma...@adobe.com.INVALID>]
>> >>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>> >>> users@flex.apache.org<ma...@flex.apache.org>;
>> >>> ngranon@idylog.com<ma...@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"
>> >>> <ng...@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<ma...@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
>> >>> >> <ng...@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
>> >>> >
>> >>
>> >>
>> >
>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Peter Ent <pe...@adobe.com>.
I'm working on a sample page based on this idea. I hope to have at least
two different ways of presenting this information from which to choose. I
will publish it on my home.apache.org site as soon as it is completed.
—peter
On 9/30/17, 7:47 AM, "Idylog - Nicolas Granon" <ng...@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
>> <pi...@gmail.com>>
>> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
>> <us...@royale.apache.org>>
>> Date: Friday, September 29, 2017 at 5:00 PM
>> To: "users@royale.apache.org<ma...@royale.apache.org>"
>> <us...@royale.apache.org>>,
>> "users@flex.apache.org<ma...@flex.apache.org>"
>> <us...@flex.apache.org>>,
>> "ngranon@idylog.com<ma...@idylog.com>"
>> <ng...@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
>> <ah...@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"
>> <pe...@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"
>> <ng...@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<ma...@adobe.com.INVALID>]
>> >>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>> >>> users@flex.apache.org<ma...@flex.apache.org>;
>> >>> ngranon@idylog.com<ma...@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"
>> >>> <ng...@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<ma...@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
>> >>> >> <ng...@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
>> >>> >
>> >>
>> >>
>> >
>
>
RE: [Royale] Flex to FlexJS migration path
Posted by Idylog - Nicolas Granon <ng...@idylog.com>.
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
> <pi...@gmail.com>>
> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
> <us...@royale.apache.org>>
> Date: Friday, September 29, 2017 at 5:00 PM
> To: "users@royale.apache.org<ma...@royale.apache.org>"
> <us...@royale.apache.org>>,
> "users@flex.apache.org<ma...@flex.apache.org>"
> <us...@flex.apache.org>>,
> "ngranon@idylog.com<ma...@idylog.com>"
> <ng...@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
> <ah...@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"
> <pe...@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"
> <ng...@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<ma...@adobe.com.INVALID>]
> >>> Envoyé : jeudi 28 septembre 2017 22:32 À :
> >>> users@flex.apache.org<ma...@flex.apache.org>;
> >>> ngranon@idylog.com<ma...@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"
> >>> <ng...@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<ma...@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
> >>> >> <ng...@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
> >>> >
> >>
> >>
> >
RE: [Royale] Flex to FlexJS migration path
Posted by Idylog - Nicolas Granon <ng...@idylog.com>.
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
> <pi...@gmail.com>>
> Reply-To: "users@royale.apache.org<ma...@royale.apache.org>"
> <us...@royale.apache.org>>
> Date: Friday, September 29, 2017 at 5:00 PM
> To: "users@royale.apache.org<ma...@royale.apache.org>"
> <us...@royale.apache.org>>,
> "users@flex.apache.org<ma...@flex.apache.org>"
> <us...@flex.apache.org>>,
> "ngranon@idylog.com<ma...@idylog.com>"
> <ng...@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
> <ah...@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"
> <pe...@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"
> <ng...@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<ma...@adobe.com.INVALID>]
> >>> Envoyé : jeudi 28 septembre 2017 22:32 À :
> >>> users@flex.apache.org<ma...@flex.apache.org>;
> >>> ngranon@idylog.com<ma...@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"
> >>> <ng...@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<ma...@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
> >>> >> <ng...@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
> >>> >
> >>
> >>
> >
Re: [Royale] Flex to FlexJS migration path
Posted by Alex Harui <ah...@adobe.com>.
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 <pi...@gmail.com>>
Reply-To: "users@royale.apache.org<ma...@royale.apache.org>" <us...@royale.apache.org>>
Date: Friday, September 29, 2017 at 5:00 PM
To: "users@royale.apache.org<ma...@royale.apache.org>" <us...@royale.apache.org>>, "users@flex.apache.org<ma...@flex.apache.org>" <us...@flex.apache.org>>, "ngranon@idylog.com<ma...@idylog.com>" <ng...@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 <ah...@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" <pe...@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" <ng...@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<ma...@adobe.com.INVALID>]
>>> Envoyé : jeudi 28 septembre 2017 22:32
>>> À : users@flex.apache.org<ma...@flex.apache.org>; ngranon@idylog.com<ma...@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" <ng...@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<ma...@gmail.com>]
>>> >> Envoyé : jeudi 28 septembre 2017 19:08 À : users@flex.apache.org<ma...@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%2Fcwik
>>> i
>>> >>.ap
>>> >>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&sdata=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>%2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d
>>> a
>>> >>ta=
>>> >>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed
>>> 2
>>> >>c17
>>> >>8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3Xruu84
>>> A
>>> >>q88
>>> >>7xFTPSj2DuB%2B0%3D&reserved=0
>>> >> es+and+Layouts
>>> >> [2]
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fapache%2Froyale-
>>> asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs&data=02
>>> >>%7C
>>> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
>>> d
>>> >>ece
>>> >>e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR6MDc%2
>>> B
>>> >>t1Y
>>> >>YMHGPVL7jA%3D&reserved=0
>>> >> [3]
>>> >>
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fapache%2Froyale-
>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>> >>88%
>>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
>>> =
>>> >>xB2
>>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>>> >>
>>> >>asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apache/
>>> f
>>> >>l
>>> >> ex/html
>>> >> [4]
>>> >>
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
>>> i
>>> >>.ap
>>> >>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&sdata=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat
>>> a
>>> >>=02
>>> >>%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c
>>> 1
>>> >>78d
>>> >>ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7a8lQTz
>>> L
>>> >>8KG
>>> >>N7kM0uCu2z4%3D&reserved=0
>>> >> 28
>>> >> [5]
>>> >>
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fapache%2Froyale-
>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>> >>88%
>>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
>>> =
>>> >>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%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fapache%2Froyale-
>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>> >>88%
>>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
>>> =
>>> >>xB2
>>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>>> >> asjs/tree/develop/examples/flexjs/MDLExample
>>> >> [7]
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgetm
>>> d
>>> >>l.i
>>> >>o%2Fcomponents%2Findex.html&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d
>>> 5
>>> >>06a
>>> >>92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624
>>> &
>>> >>sda
>>> >>ta=U6IQ%2Fikcn61Row6PjP%2FLF%2F4kqle2pe4U%2BEgAuxMfL90%3D&reserved=0
>>> >> [8]
>>> >>
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
>>> i
>>> >>.ap
>>> >>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&sdata=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>%2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data
>>> =
>>> >>02%
>>> >>7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c1
>>> 7
>>> >>8de
>>> >>cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xRtJrdXn
>>> D
>>> >>Lai
>>> >>3UM8LpiO7APc%3D&reserved=0
>>> >>
>>> >> Thanks, Piotr
>>> >>
>>> >>
>>> >> 2017-09-28 17:58 GMT+02:00 Idylog - Nicolas Granon
>>> >> <ng...@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%2Fcwik
>>> i
>>> >>.ap
>>> >>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&sdata=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0
>>> 2
>>> >>%7C
>>> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
>>> d
>>> >>ece
>>> >>e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoLzLHc8v
>>> 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%2Fwww.l
>>> i
>>> >>nke
>>> >>din.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&sdata=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%3A%2F%2Fedin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&sdata=7rUvU4thZJ3Ja1S4aMg4RwxKGwoMgN4%2FIZ4RY9W4MwE%3D&reserved=0>%2Fin%2Fpiotr-zarzycki-
>>> 92a53552&data=02%7C01%7C%7Cab4e20a981d4
>>> >>4a9
>>> >>ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422
>>> 2
>>> >>459
>>> >>42183624&sdata=tSGDWZ5AhBPECbf1%2Fy9R2u9N4qwJ03VBhzwzNsPTcCM%3D&reser
>>> v
>>> >>ed=
>>> >>0>
>>> >>
>>> >> GitHub:
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fpiotrzarzycki21&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>> 8
>>> >>8%7
>>> >>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=
>>> l
>>> >>Mum
>>> >>yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0
>>> >
>>
>>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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 <pi...@gmail.com>>
Reply-To: "users@royale.apache.org<ma...@royale.apache.org>" <us...@royale.apache.org>>
Date: Friday, September 29, 2017 at 5:00 PM
To: "users@royale.apache.org<ma...@royale.apache.org>" <us...@royale.apache.org>>, "users@flex.apache.org<ma...@flex.apache.org>" <us...@flex.apache.org>>, "ngranon@idylog.com<ma...@idylog.com>" <ng...@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 <ah...@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" <pe...@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" <ng...@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<ma...@adobe.com.INVALID>]
>>> Envoyé : jeudi 28 septembre 2017 22:32
>>> À : users@flex.apache.org<ma...@flex.apache.org>; ngranon@idylog.com<ma...@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" <ng...@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<ma...@gmail.com>]
>>> >> Envoyé : jeudi 28 septembre 2017 19:08 À : users@flex.apache.org<ma...@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%2Fcwik
>>> i
>>> >>.ap
>>> >>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&sdata=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>%2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d
>>> a
>>> >>ta=
>>> >>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed
>>> 2
>>> >>c17
>>> >>8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3Xruu84
>>> A
>>> >>q88
>>> >>7xFTPSj2DuB%2B0%3D&reserved=0
>>> >> es+and+Layouts
>>> >> [2]
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fapache%2Froyale-
>>> asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs&data=02
>>> >>%7C
>>> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
>>> d
>>> >>ece
>>> >>e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR6MDc%2
>>> B
>>> >>t1Y
>>> >>YMHGPVL7jA%3D&reserved=0
>>> >> [3]
>>> >>
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fapache%2Froyale-
>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>> >>88%
>>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
>>> =
>>> >>xB2
>>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>>> >>
>>> >>asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apache/
>>> f
>>> >>l
>>> >> ex/html
>>> >> [4]
>>> >>
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
>>> i
>>> >>.ap
>>> >>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&sdata=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat
>>> a
>>> >>=02
>>> >>%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c
>>> 1
>>> >>78d
>>> >>ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7a8lQTz
>>> L
>>> >>8KG
>>> >>N7kM0uCu2z4%3D&reserved=0
>>> >> 28
>>> >> [5]
>>> >>
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fapache%2Froyale-
>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>> >>88%
>>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
>>> =
>>> >>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%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fapache%2Froyale-
>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>> >>88%
>>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
>>> =
>>> >>xB2
>>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>>> >> asjs/tree/develop/examples/flexjs/MDLExample
>>> >> [7]
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgetm
>>> d
>>> >>l.i
>>> >>o%2Fcomponents%2Findex.html&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d
>>> 5
>>> >>06a
>>> >>92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624
>>> &
>>> >>sda
>>> >>ta=U6IQ%2Fikcn61Row6PjP%2FLF%2F4kqle2pe4U%2BEgAuxMfL90%3D&reserved=0
>>> >> [8]
>>> >>
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
>>> i
>>> >>.ap
>>> >>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&sdata=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>%2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data
>>> =
>>> >>02%
>>> >>7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c1
>>> 7
>>> >>8de
>>> >>cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xRtJrdXn
>>> D
>>> >>Lai
>>> >>3UM8LpiO7APc%3D&reserved=0
>>> >>
>>> >> Thanks, Piotr
>>> >>
>>> >>
>>> >> 2017-09-28 17:58 GMT+02:00 Idylog - Nicolas Granon
>>> >> <ng...@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%2Fcwik
>>> i
>>> >>.ap
>>> >>ache.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fache.org&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&sdata=%2F6sb09oYhlfeID4ijmffAztP0xRxJ9WZzj943DSgJHg%3D&reserved=0>%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0
>>> 2
>>> >>%7C
>>> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
>>> d
>>> >>ece
>>> >>e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoLzLHc8v
>>> 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%2Fwww.l
>>> i
>>> >>nke
>>> >>din.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&sdata=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%3A%2F%2Fedin.com&data=02%7C01%7C%7C8514d1b1725d45e0a5b908d507964788%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636423264392032256&sdata=7rUvU4thZJ3Ja1S4aMg4RwxKGwoMgN4%2FIZ4RY9W4MwE%3D&reserved=0>%2Fin%2Fpiotr-zarzycki-
>>> 92a53552&data=02%7C01%7C%7Cab4e20a981d4
>>> >>4a9
>>> >>ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422
>>> 2
>>> >>459
>>> >>42183624&sdata=tSGDWZ5AhBPECbf1%2Fy9R2u9N4qwJ03VBhzwzNsPTcCM%3D&reser
>>> v
>>> >>ed=
>>> >>0>
>>> >>
>>> >> GitHub:
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fpiotrzarzycki21&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>> 8
>>> >>8%7
>>> >>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=
>>> l
>>> >>Mum
>>> >>yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0
>>> >
>>
>>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Piotr Zarzycki <pi...@gmail.com>.
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 <ah...@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" <pe...@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" <ng...@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]
> >>> Envoyé : jeudi 28 septembre 2017 22:32
> >>> À : users@flex.apache.org; 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" <ng...@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]
> >>> >> Envoyé : jeudi 28 septembre 2017 19:08 À : 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%2Fcwik
> >>> i
> >>> >>.ap
> >>> >>ache.org
> %2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d
> >>> a
> >>> >>ta=
> >>> >>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed
> >>> 2
> >>> >>c17
> >>> >>8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3Xruu84
> >>> A
> >>> >>q88
> >>> >>7xFTPSj2DuB%2B0%3D&reserved=0
> >>> >> es+and+Layouts
> >>> >> [2]
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >>> u
> >>> >>b.c
> >>> >>om%2Fapache%2Froyale-
> >>> asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs&data=02
> >>> >>%7C
> >>> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
> >>> d
> >>> >>ece
> >>> >>e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR6MDc%2
> >>> B
> >>> >>t1Y
> >>> >>YMHGPVL7jA%3D&reserved=0
> >>> >> [3]
> >>> >>
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >>> u
> >>> >>b.c
> >>> >>om%2Fapache%2Froyale-
> >>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >>> >>88%
> >>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
> >>> =
> >>> >>xB2
> >>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
> >>> >>
> >>> >>asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apache/
> >>> f
> >>> >>l
> >>> >> ex/html
> >>> >> [4]
> >>> >>
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
> >>> i
> >>> >>.ap
> >>> >>ache.org
> %2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat
> >>> a
> >>> >>=02
> >>> >>%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c
> >>> 1
> >>> >>78d
> >>> >>ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7a8lQTz
> >>> L
> >>> >>8KG
> >>> >>N7kM0uCu2z4%3D&reserved=0
> >>> >> 28
> >>> >> [5]
> >>> >>
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >>> u
> >>> >>b.c
> >>> >>om%2Fapache%2Froyale-
> >>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >>> >>88%
> >>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
> >>> =
> >>> >>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%2Fgith
> >>> u
> >>> >>b.c
> >>> >>om%2Fapache%2Froyale-
> >>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >>> >>88%
> >>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
> >>> =
> >>> >>xB2
> >>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
> >>> >> asjs/tree/develop/examples/flexjs/MDLExample
> >>> >> [7]
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgetm
> >>> d
> >>> >>l.i
> >>> >>o%2Fcomponents%2Findex.html&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d
> >>> 5
> >>> >>06a
> >>> >>92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624
> >>> &
> >>> >>sda
> >>> >>ta=U6IQ%2Fikcn61Row6PjP%2FLF%2F4kqle2pe4U%2BEgAuxMfL90%3D&reserved=0
> >>> >> [8]
> >>> >>
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
> >>> i
> >>> >>.ap
> >>> >>ache.org
> %2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data
> >>> =
> >>> >>02%
> >>> >>7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c1
> >>> 7
> >>> >>8de
> >>> >>cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xRtJrdXn
> >>> D
> >>> >>Lai
> >>> >>3UM8LpiO7APc%3D&reserved=0
> >>> >>
> >>> >> Thanks, Piotr
> >>> >>
> >>> >>
> >>> >> 2017-09-28 17:58 GMT+02:00 Idylog - Nicolas Granon
> >>> >> <ng...@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%2Fcwik
> >>> i
> >>> >>.ap
> >>> >>ache.org
> %2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0
> >>> 2
> >>> >>%7C
> >>> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
> >>> d
> >>> >>ece
> >>> >>e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoLzLHc8v
> >>> 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%2Fwww.l
> >>> i
> >>> >>nke
> >>> >>din.com
> %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%2Fin%2Fpiotr-zarzycki-
> >>> 92a53552&data=02%7C01%7C%7Cab4e20a981d4
> >>> >>4a9
> >>> >>ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422
> >>> 2
> >>> >>459
> >>> >>42183624&sdata=tSGDWZ5AhBPECbf1%2Fy9R2u9N4qwJ03VBhzwzNsPTcCM%3D&reser
> >>> v
> >>> >>ed=
> >>> >>0>
> >>> >>
> >>> >> GitHub:
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >>> u
> >>> >>b.c
> >>> >>om%2Fpiotrzarzycki21&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >>> 8
> >>> >>8%7
> >>> >>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=
> >>> l
> >>> >>Mum
> >>> >>yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0
> >>> >
> >>
> >>
> >
>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Piotr Zarzycki <pi...@gmail.com>.
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 <ah...@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" <pe...@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" <ng...@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]
> >>> Envoyé : jeudi 28 septembre 2017 22:32
> >>> À : users@flex.apache.org; 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" <ng...@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]
> >>> >> Envoyé : jeudi 28 septembre 2017 19:08 À : 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%2Fcwik
> >>> i
> >>> >>.ap
> >>> >>ache.org
> %2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d
> >>> a
> >>> >>ta=
> >>> >>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed
> >>> 2
> >>> >>c17
> >>> >>8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3Xruu84
> >>> A
> >>> >>q88
> >>> >>7xFTPSj2DuB%2B0%3D&reserved=0
> >>> >> es+and+Layouts
> >>> >> [2]
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >>> u
> >>> >>b.c
> >>> >>om%2Fapache%2Froyale-
> >>> asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs&data=02
> >>> >>%7C
> >>> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
> >>> d
> >>> >>ece
> >>> >>e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR6MDc%2
> >>> B
> >>> >>t1Y
> >>> >>YMHGPVL7jA%3D&reserved=0
> >>> >> [3]
> >>> >>
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >>> u
> >>> >>b.c
> >>> >>om%2Fapache%2Froyale-
> >>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >>> >>88%
> >>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
> >>> =
> >>> >>xB2
> >>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
> >>> >>
> >>> >>asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apache/
> >>> f
> >>> >>l
> >>> >> ex/html
> >>> >> [4]
> >>> >>
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
> >>> i
> >>> >>.ap
> >>> >>ache.org
> %2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat
> >>> a
> >>> >>=02
> >>> >>%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c
> >>> 1
> >>> >>78d
> >>> >>ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7a8lQTz
> >>> L
> >>> >>8KG
> >>> >>N7kM0uCu2z4%3D&reserved=0
> >>> >> 28
> >>> >> [5]
> >>> >>
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >>> u
> >>> >>b.c
> >>> >>om%2Fapache%2Froyale-
> >>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >>> >>88%
> >>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
> >>> =
> >>> >>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%2Fgith
> >>> u
> >>> >>b.c
> >>> >>om%2Fapache%2Froyale-
> >>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >>> >>88%
> >>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
> >>> =
> >>> >>xB2
> >>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
> >>> >> asjs/tree/develop/examples/flexjs/MDLExample
> >>> >> [7]
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgetm
> >>> d
> >>> >>l.i
> >>> >>o%2Fcomponents%2Findex.html&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d
> >>> 5
> >>> >>06a
> >>> >>92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624
> >>> &
> >>> >>sda
> >>> >>ta=U6IQ%2Fikcn61Row6PjP%2FLF%2F4kqle2pe4U%2BEgAuxMfL90%3D&reserved=0
> >>> >> [8]
> >>> >>
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
> >>> i
> >>> >>.ap
> >>> >>ache.org
> %2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data
> >>> =
> >>> >>02%
> >>> >>7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c1
> >>> 7
> >>> >>8de
> >>> >>cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xRtJrdXn
> >>> D
> >>> >>Lai
> >>> >>3UM8LpiO7APc%3D&reserved=0
> >>> >>
> >>> >> Thanks, Piotr
> >>> >>
> >>> >>
> >>> >> 2017-09-28 17:58 GMT+02:00 Idylog - Nicolas Granon
> >>> >> <ng...@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%2Fcwik
> >>> i
> >>> >>.ap
> >>> >>ache.org
> %2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0
> >>> 2
> >>> >>%7C
> >>> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
> >>> d
> >>> >>ece
> >>> >>e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoLzLHc8v
> >>> 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%2Fwww.l
> >>> i
> >>> >>nke
> >>> >>din.com
> %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%2Fin%2Fpiotr-zarzycki-
> >>> 92a53552&data=02%7C01%7C%7Cab4e20a981d4
> >>> >>4a9
> >>> >>ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422
> >>> 2
> >>> >>459
> >>> >>42183624&sdata=tSGDWZ5AhBPECbf1%2Fy9R2u9N4qwJ03VBhzwzNsPTcCM%3D&reser
> >>> v
> >>> >>ed=
> >>> >>0>
> >>> >>
> >>> >> GitHub:
> >>> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >>> u
> >>> >>b.c
> >>> >>om%2Fpiotrzarzycki21&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >>> 8
> >>> >>8%7
> >>> >>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=
> >>> l
> >>> >>Mum
> >>> >>yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0
> >>> >
> >>
> >>
> >
>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <pe...@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" <ng...@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]
>>> Envoyé : jeudi 28 septembre 2017 22:32
>>> À : users@flex.apache.org; 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" <ng...@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]
>>> >> Envoyé : jeudi 28 septembre 2017 19:08 À : 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%2Fcwik
>>> i
>>> >>.ap
>>> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d
>>> a
>>> >>ta=
>>> >>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed
>>> 2
>>> >>c17
>>> >>8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3Xruu84
>>> A
>>> >>q88
>>> >>7xFTPSj2DuB%2B0%3D&reserved=0
>>> >> es+and+Layouts
>>> >> [2]
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fapache%2Froyale-
>>> asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs&data=02
>>> >>%7C
>>> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
>>> d
>>> >>ece
>>> >>e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR6MDc%2
>>> B
>>> >>t1Y
>>> >>YMHGPVL7jA%3D&reserved=0
>>> >> [3]
>>> >>
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fapache%2Froyale-
>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>> >>88%
>>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
>>> =
>>> >>xB2
>>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>>> >>
>>> >>asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apache/
>>> f
>>> >>l
>>> >> ex/html
>>> >> [4]
>>> >>
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
>>> i
>>> >>.ap
>>> >>ache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat
>>> a
>>> >>=02
>>> >>%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c
>>> 1
>>> >>78d
>>> >>ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7a8lQTz
>>> L
>>> >>8KG
>>> >>N7kM0uCu2z4%3D&reserved=0
>>> >> 28
>>> >> [5]
>>> >>
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fapache%2Froyale-
>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>> >>88%
>>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
>>> =
>>> >>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%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fapache%2Froyale-
>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>> >>88%
>>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
>>> =
>>> >>xB2
>>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>>> >> asjs/tree/develop/examples/flexjs/MDLExample
>>> >> [7]
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgetm
>>> d
>>> >>l.i
>>> >>o%2Fcomponents%2Findex.html&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d
>>> 5
>>> >>06a
>>> >>92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624
>>> &
>>> >>sda
>>> >>ta=U6IQ%2Fikcn61Row6PjP%2FLF%2F4kqle2pe4U%2BEgAuxMfL90%3D&reserved=0
>>> >> [8]
>>> >>
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
>>> i
>>> >>.ap
>>> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data
>>> =
>>> >>02%
>>> >>7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c1
>>> 7
>>> >>8de
>>> >>cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xRtJrdXn
>>> D
>>> >>Lai
>>> >>3UM8LpiO7APc%3D&reserved=0
>>> >>
>>> >> Thanks, Piotr
>>> >>
>>> >>
>>> >> 2017-09-28 17:58 GMT+02:00 Idylog - Nicolas Granon
>>> >> <ng...@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%2Fcwik
>>> i
>>> >>.ap
>>> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0
>>> 2
>>> >>%7C
>>> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
>>> d
>>> >>ece
>>> >>e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoLzLHc8v
>>> 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%2Fwww.l
>>> i
>>> >>nke
>>> >>din.com%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%2Fin%2Fpiotr-zarzycki-
>>> 92a53552&data=02%7C01%7C%7Cab4e20a981d4
>>> >>4a9
>>> >>ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422
>>> 2
>>> >>459
>>> >>42183624&sdata=tSGDWZ5AhBPECbf1%2Fy9R2u9N4qwJ03VBhzwzNsPTcCM%3D&reser
>>> v
>>> >>ed=
>>> >>0>
>>> >>
>>> >> GitHub:
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fpiotrzarzycki21&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>> 8
>>> >>8%7
>>> >>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=
>>> l
>>> >>Mum
>>> >>yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0
>>> >
>>
>>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Alex Harui <ah...@adobe.com>.
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" <pe...@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" <ng...@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]
>>> Envoyé : jeudi 28 septembre 2017 22:32
>>> À : users@flex.apache.org; 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" <ng...@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]
>>> >> Envoyé : jeudi 28 septembre 2017 19:08 À : 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%2Fcwik
>>> i
>>> >>.ap
>>> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d
>>> a
>>> >>ta=
>>> >>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed
>>> 2
>>> >>c17
>>> >>8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3Xruu84
>>> A
>>> >>q88
>>> >>7xFTPSj2DuB%2B0%3D&reserved=0
>>> >> es+and+Layouts
>>> >> [2]
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fapache%2Froyale-
>>> asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs&data=02
>>> >>%7C
>>> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
>>> d
>>> >>ece
>>> >>e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR6MDc%2
>>> B
>>> >>t1Y
>>> >>YMHGPVL7jA%3D&reserved=0
>>> >> [3]
>>> >>
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fapache%2Froyale-
>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>> >>88%
>>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
>>> =
>>> >>xB2
>>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>>> >>
>>> >>asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apache/
>>> f
>>> >>l
>>> >> ex/html
>>> >> [4]
>>> >>
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
>>> i
>>> >>.ap
>>> >>ache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat
>>> a
>>> >>=02
>>> >>%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c
>>> 1
>>> >>78d
>>> >>ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7a8lQTz
>>> L
>>> >>8KG
>>> >>N7kM0uCu2z4%3D&reserved=0
>>> >> 28
>>> >> [5]
>>> >>
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fapache%2Froyale-
>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>> >>88%
>>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
>>> =
>>> >>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%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fapache%2Froyale-
>>> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>> >>88%
>>> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
>>> =
>>> >>xB2
>>> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>>> >> asjs/tree/develop/examples/flexjs/MDLExample
>>> >> [7]
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgetm
>>> d
>>> >>l.i
>>> >>o%2Fcomponents%2Findex.html&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d
>>> 5
>>> >>06a
>>> >>92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624
>>> &
>>> >>sda
>>> >>ta=U6IQ%2Fikcn61Row6PjP%2FLF%2F4kqle2pe4U%2BEgAuxMfL90%3D&reserved=0
>>> >> [8]
>>> >>
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
>>> i
>>> >>.ap
>>> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data
>>> =
>>> >>02%
>>> >>7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c1
>>> 7
>>> >>8de
>>> >>cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xRtJrdXn
>>> D
>>> >>Lai
>>> >>3UM8LpiO7APc%3D&reserved=0
>>> >>
>>> >> Thanks, Piotr
>>> >>
>>> >>
>>> >> 2017-09-28 17:58 GMT+02:00 Idylog - Nicolas Granon
>>> >> <ng...@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%2Fcwik
>>> i
>>> >>.ap
>>> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0
>>> 2
>>> >>%7C
>>> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
>>> d
>>> >>ece
>>> >>e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoLzLHc8v
>>> 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%2Fwww.l
>>> i
>>> >>nke
>>> >>din.com%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%2Fin%2Fpiotr-zarzycki-
>>> 92a53552&data=02%7C01%7C%7Cab4e20a981d4
>>> >>4a9
>>> >>ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422
>>> 2
>>> >>459
>>> >>42183624&sdata=tSGDWZ5AhBPECbf1%2Fy9R2u9N4qwJ03VBhzwzNsPTcCM%3D&reser
>>> v
>>> >>ed=
>>> >>0>
>>> >>
>>> >> GitHub:
>>> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>>> u
>>> >>b.c
>>> >>om%2Fpiotrzarzycki21&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
>>> 8
>>> >>8%7
>>> >>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=
>>> l
>>> >>Mum
>>> >>yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0
>>> >
>>
>>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Mark Kessler <ke...@gmail.com>.
It's a good idea. Would definitely make a transition easier if I
could plan out over time. Being able to stage changes to migrate more
easily would be welcome.
-Mark K
On Fri, Sep 29, 2017 at 2:40 PM, Peter Ent <pe...@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" <ng...@idylog.com> wrote:
>
Re: [Royale] Flex to FlexJS migration path
Posted by Piotr Zarzycki <pi...@gmail.com>.
Hi Peter,
I was also thinking how to help Nicolas and other folks who came with
similar problems.
I believe such table should contains Flex Component/Royale
Component/Beads/Description -
Flex Component - Just name
Royale Component - Name/Names of the Views if there are some which doing
more
Beads - Possible Beads used by components
Description - Maybe sub pages with longer summary
I was going to start this one in the repository where Olaf put his
documentation idea. But fill free start it in current Royale repo - I hope
all Olaf's effort will be moved there too.
If you put it nicely as an wiki - we can later make it as github page file.
Olaf has following section [1] - "Migrate from Flex to FlexJs"
[1] https://github.com/ok-at-github/flexjs-docs/wiki
Piotr
On Fri, Sep 29, 2017, 20:40 Peter Ent <pe...@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" <ng...@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]
> >> Envoyé : jeudi 28 septembre 2017 22:32
> >> À : users@flex.apache.org; 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" <ng...@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]
> >> >> Envoyé : jeudi 28 septembre 2017 19:08 À : 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%2Fcwik
> >> i
> >> >>.ap
> >> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d
> >> a
> >> >>ta=
> >> >>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed
> >> 2
> >> >>c17
> >> >>8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3Xruu84
> >> A
> >> >>q88
> >> >>7xFTPSj2DuB%2B0%3D&reserved=0
> >> >> es+and+Layouts
> >> >> [2]
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >> u
> >> >>b.c
> >> >>om%2Fapache%2Froyale-
> >> asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs&data=02
> >> >>%7C
> >> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
> >> d
> >> >>ece
> >> >>e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR6MDc%2
> >> B
> >> >>t1Y
> >> >>YMHGPVL7jA%3D&reserved=0
> >> >> [3]
> >> >>
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >> u
> >> >>b.c
> >> >>om%2Fapache%2Froyale-
> >> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >> >>88%
> >> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
> >> =
> >> >>xB2
> >> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
> >> >>
> >> >>asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apache/
> >> f
> >> >>l
> >> >> ex/html
> >> >> [4]
> >> >>
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
> >> i
> >> >>.ap
> >> >>ache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat
> >> a
> >> >>=02
> >> >>%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c
> >> 1
> >> >>78d
> >> >>ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7a8lQTz
> >> L
> >> >>8KG
> >> >>N7kM0uCu2z4%3D&reserved=0
> >> >> 28
> >> >> [5]
> >> >>
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >> u
> >> >>b.c
> >> >>om%2Fapache%2Froyale-
> >> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >> >>88%
> >> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
> >> =
> >> >>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%2Fgith
> >> u
> >> >>b.c
> >> >>om%2Fapache%2Froyale-
> >> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >> >>88%
> >> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
> >> =
> >> >>xB2
> >> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
> >> >> asjs/tree/develop/examples/flexjs/MDLExample
> >> >> [7]
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgetm
> >> d
> >> >>l.i
> >> >>o%2Fcomponents%2Findex.html&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d
> >> 5
> >> >>06a
> >> >>92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624
> >> &
> >> >>sda
> >> >>ta=U6IQ%2Fikcn61Row6PjP%2FLF%2F4kqle2pe4U%2BEgAuxMfL90%3D&reserved=0
> >> >> [8]
> >> >>
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
> >> i
> >> >>.ap
> >> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data
> >> =
> >> >>02%
> >> >>7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c1
> >> 7
> >> >>8de
> >> >>cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xRtJrdXn
> >> D
> >> >>Lai
> >> >>3UM8LpiO7APc%3D&reserved=0
> >> >>
> >> >> Thanks, Piotr
> >> >>
> >> >>
> >> >> 2017-09-28 17:58 GMT+02:00 Idylog - Nicolas Granon
> >> >> <ng...@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%2Fcwik
> >> i
> >> >>.ap
> >> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0
> >> 2
> >> >>%7C
> >> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
> >> d
> >> >>ece
> >> >>e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoLzLHc8v
> >> 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%2Fwww.l
> >> i
> >> >>nke
> >> >>din.com%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%2Fin%2Fpiotr-zarzycki-
> >> 92a53552&data=02%7C01%7C%7Cab4e20a981d4
> >> >>4a9
> >> >>ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422
> >> 2
> >> >>459
> >> >>42183624&sdata=tSGDWZ5AhBPECbf1%2Fy9R2u9N4qwJ03VBhzwzNsPTcCM%3D&reser
> >> v
> >> >>ed=
> >> >>0>
> >> >>
> >> >> GitHub:
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >> u
> >> >>b.c
> >> >>om%2Fpiotrzarzycki21&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >> 8
> >> >>8%7
> >> >>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=
> >> l
> >> >>Mum
> >> >>yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0
> >> >
> >
> >
>
>
Re: [Royale] Flex to FlexJS migration path
Posted by Piotr Zarzycki <pi...@gmail.com>.
Hi Peter,
I was also thinking how to help Nicolas and other folks who came with
similar problems.
I believe such table should contains Flex Component/Royale
Component/Beads/Description -
Flex Component - Just name
Royale Component - Name/Names of the Views if there are some which doing
more
Beads - Possible Beads used by components
Description - Maybe sub pages with longer summary
I was going to start this one in the repository where Olaf put his
documentation idea. But fill free start it in current Royale repo - I hope
all Olaf's effort will be moved there too.
If you put it nicely as an wiki - we can later make it as github page file.
Olaf has following section [1] - "Migrate from Flex to FlexJs"
[1] https://github.com/ok-at-github/flexjs-docs/wiki
Piotr
On Fri, Sep 29, 2017, 20:40 Peter Ent <pe...@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" <ng...@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]
> >> Envoyé : jeudi 28 septembre 2017 22:32
> >> À : users@flex.apache.org; 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" <ng...@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]
> >> >> Envoyé : jeudi 28 septembre 2017 19:08 À : 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%2Fcwik
> >> i
> >> >>.ap
> >> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&d
> >> a
> >> >>ta=
> >> >>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed
> >> 2
> >> >>c17
> >> >>8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3Xruu84
> >> A
> >> >>q88
> >> >>7xFTPSj2DuB%2B0%3D&reserved=0
> >> >> es+and+Layouts
> >> >> [2]
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >> u
> >> >>b.c
> >> >>om%2Fapache%2Froyale-
> >> asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs&data=02
> >> >>%7C
> >> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
> >> d
> >> >>ece
> >> >>e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR6MDc%2
> >> B
> >> >>t1Y
> >> >>YMHGPVL7jA%3D&reserved=0
> >> >> [3]
> >> >>
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >> u
> >> >>b.c
> >> >>om%2Fapache%2Froyale-
> >> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >> >>88%
> >> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
> >> =
> >> >>xB2
> >> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
> >> >>
> >> >>asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apache/
> >> f
> >> >>l
> >> >> ex/html
> >> >> [4]
> >> >>
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
> >> i
> >> >>.ap
> >> >>ache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&dat
> >> a
> >> >>=02
> >> >>%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c
> >> 1
> >> >>78d
> >> >>ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7a8lQTz
> >> L
> >> >>8KG
> >> >>N7kM0uCu2z4%3D&reserved=0
> >> >> 28
> >> >> [5]
> >> >>
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >> u
> >> >>b.c
> >> >>om%2Fapache%2Froyale-
> >> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >> >>88%
> >> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
> >> =
> >> >>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%2Fgith
> >> u
> >> >>b.c
> >> >>om%2Fapache%2Froyale-
> >> &data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >> >>88%
> >> >>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata
> >> =
> >> >>xB2
> >> >>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
> >> >> asjs/tree/develop/examples/flexjs/MDLExample
> >> >> [7]
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgetm
> >> d
> >> >>l.i
> >> >>o%2Fcomponents%2Findex.html&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d
> >> 5
> >> >>06a
> >> >>92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624
> >> &
> >> >>sda
> >> >>ta=U6IQ%2Fikcn61Row6PjP%2FLF%2F4kqle2pe4U%2BEgAuxMfL90%3D&reserved=0
> >> >> [8]
> >> >>
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwik
> >> i
> >> >>.ap
> >> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data
> >> =
> >> >>02%
> >> >>7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c1
> >> 7
> >> >>8de
> >> >>cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xRtJrdXn
> >> D
> >> >>Lai
> >> >>3UM8LpiO7APc%3D&reserved=0
> >> >>
> >> >> Thanks, Piotr
> >> >>
> >> >>
> >> >> 2017-09-28 17:58 GMT+02:00 Idylog - Nicolas Granon
> >> >> <ng...@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%2Fcwik
> >> i
> >> >>.ap
> >> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=0
> >> 2
> >> >>%7C
> >> >>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178
> >> d
> >> >>ece
> >> >>e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoLzLHc8v
> >> 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%2Fwww.l
> >> i
> >> >>nke
> >> >>din.com%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%2Fin%2Fpiotr-zarzycki-
> >> 92a53552&data=02%7C01%7C%7Cab4e20a981d4
> >> >>4a9
> >> >>ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422
> >> 2
> >> >>459
> >> >>42183624&sdata=tSGDWZ5AhBPECbf1%2Fy9R2u9N4qwJ03VBhzwzNsPTcCM%3D&reser
> >> v
> >> >>ed=
> >> >>0>
> >> >>
> >> >> GitHub:
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >> u
> >> >>b.c
> >> >>om%2Fpiotrzarzycki21&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a926
> >> 8
> >> >>8%7
> >> >>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=
> >> l
> >> >>Mum
> >> >>yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0
> >> >
> >
> >
>
>