[Royale] Flex to FlexJS migration path

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[Royale] Flex to FlexJS migration path

Peter Ent-2
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" <[hidden email]> 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:[hidden email]]
>> Envoyé : jeudi 28 septembre 2017 22:32
>> À : [hidden email]; [hidden email]
>> 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" <[hidden email]>
>> 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:[hidden email]]
>> >> Envoyé : jeudi 28 septembre 2017 19:08 À : [hidden email]
>> >> 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
>> >> <[hidden email]>:
>> >>
>> >> > 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
>> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Royale] Flex to FlexJS migration path

piotrz
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 <[hidden email]> 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" <[hidden email]> 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:[hidden email]]
> >> Envoyé : jeudi 28 septembre 2017 22:32
> >> À : [hidden email]; [hidden email]
> >> 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" <[hidden email]>
> >> 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:[hidden email]]
> >> >> Envoyé : jeudi 28 septembre 2017 19:08 À : [hidden email]
> >> >> 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
> >> >> <[hidden email]>:
> >> >>
> >> >> > 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
> >> >
> >
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Royale] Flex to FlexJS migration path

Mark Kessler
In reply to this post by Peter Ent-2
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 <[hidden email]> 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" <[hidden email]> wrote:
>
Reply | Threaded
Open this post in threaded view
|

Re: [Royale] Flex to FlexJS migration path

Alex Harui-2
In reply to this post by Peter Ent-2
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" <[hidden email]> 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" <[hidden email]> 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:[hidden email]]
>>> Envoyé : jeudi 28 septembre 2017 22:32
>>> À : [hidden email]; [hidden email]
>>> 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" <[hidden email]>
>>> 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:[hidden email]]
>>> >> Envoyé : jeudi 28 septembre 2017 19:08 À : [hidden email]
>>> >> 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
>>> >> <[hidden email]>:
>>> >>
>>> >> > 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
>>> >
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Royale] Flex to FlexJS migration path

piotrz
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 <[hidden email]> 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" <[hidden email]> 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" <[hidden email]>
> 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:[hidden email]]
> >>> Envoyé : jeudi 28 septembre 2017 22:32
> >>> À : [hidden email]; [hidden email]
> >>> 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" <[hidden email]>
> >>> 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:[hidden email]]
> >>> >> Envoyé : jeudi 28 septembre 2017 19:08 À : [hidden email]
> >>> >> 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
> >>> >> <[hidden email]>:
> >>> >>
> >>> >> > 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
> >>> >
> >>
> >>
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Royale] Flex to FlexJS migration path

Alex Harui-2
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 <[hidden email]<mailto:[hidden email]>>
Reply-To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Date: Friday, September 29, 2017 at 5:00 PM
To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>, "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>, "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
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 <[hidden email]<mailto:[hidden email]>> 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" <[hidden email]<mailto:[hidden email]>> 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" <[hidden email]<mailto:[hidden email]>> 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:[hidden email]<mailto:[hidden email]>]
>>> Envoyé : jeudi 28 septembre 2017 22:32
>>> À : [hidden email]<mailto:[hidden email]>; [hidden email]<mailto:[hidden email]>
>>> 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" <[hidden email]<mailto:[hidden email]>>
>>> 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:[hidden email]<mailto:[hidden email]>]
>>> >> Envoyé : jeudi 28 septembre 2017 19:08 À : [hidden email]<mailto:[hidden email]>
>>> >> 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
>>> >> <[hidden email]<mailto:[hidden email]>>:
>>> >>
>>> >> > 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
>>> >
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

RE: [Royale] Flex to FlexJS migration path

Idylog - Nicolas Granon
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:[hidden email]]
> Envoyé : samedi 30 septembre 2017 07:56
> À : [hidden email]; [hidden email]; [hidden email]
> 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
> <[hidden email]<mailto:[hidden email]>>
> Reply-To: "[hidden email]<mailto:[hidden email]>"
> <[hidden email]<mailto:[hidden email]>>
> Date: Friday, September 29, 2017 at 5:00 PM
> To: "[hidden email]<mailto:[hidden email]>"
> <[hidden email]<mailto:[hidden email]>>,
> "[hidden email]<mailto:[hidden email]>"
> <[hidden email]<mailto:[hidden email]>>,
> "[hidden email]<mailto:[hidden email]>"
> <[hidden email]<mailto:[hidden email]>>
> 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
> <[hidden email]<mailto:[hidden email]>> 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"
> <[hidden email]<mailto:[hidden email]>> 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"
> <[hidden email]<mailto:[hidden email]>> 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:[hidden email]<mailto:[hidden email]>]
> >>> Envoyé : jeudi 28 septembre 2017 22:32 À :
> >>> [hidden email]<mailto:[hidden email]>;
> >>> [hidden email]<mailto:[hidden email]>
> >>> 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"
> >>> <[hidden email]<mailto:[hidden email]>>
> >>> 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:[hidden email]<mailto:[hidden email]
> >>> >> m>] Envoyé : jeudi 28 septembre 2017 19:08 À :
> >>> >> [hidden email]<mailto:[hidden email]>
> >>> >> 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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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
> >>> >> <[hidden email]<mailto:[hidden email]>>:
> >>> >>
> >>> >> > 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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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
> >>> >
> >>
> >>
> >


Reply | Threaded
Open this post in threaded view
|

Re: [Royale] Flex to FlexJS migration path

Peter Ent-2
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" <[hidden email]> 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:[hidden email]]
>> Envoyé : samedi 30 septembre 2017 07:56
>> À : [hidden email]; [hidden email]; [hidden email]
>> 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
>> <[hidden email]<mailto:[hidden email]>>
>> Reply-To: "[hidden email]<mailto:[hidden email]>"
>> <[hidden email]<mailto:[hidden email]>>
>> Date: Friday, September 29, 2017 at 5:00 PM
>> To: "[hidden email]<mailto:[hidden email]>"
>> <[hidden email]<mailto:[hidden email]>>,
>> "[hidden email]<mailto:[hidden email]>"
>> <[hidden email]<mailto:[hidden email]>>,
>> "[hidden email]<mailto:[hidden email]>"
>> <[hidden email]<mailto:[hidden email]>>
>> 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
>> <[hidden email]<mailto:[hidden email]>> 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"
>> <[hidden email]<mailto:[hidden email]>> 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"
>> <[hidden email]<mailto:[hidden email]>> 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:[hidden email]<mailto:[hidden email]>]
>> >>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>> >>> [hidden email]<mailto:[hidden email]>;
>> >>> [hidden email]<mailto:[hidden email]>
>> >>> 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"
>> >>> <[hidden email]<mailto:[hidden email]>>
>> >>> 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:[hidden email]<mailto:[hidden email]
>> >>> >> m>] Envoyé : jeudi 28 septembre 2017 19:08 À :
>> >>> >> [hidden email]<mailto:[hidden email]>
>> >>> >> 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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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
>> >>> >> <[hidden email]<mailto:[hidden email]>>:
>> >>> >>
>> >>> >> > 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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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
>> >>> >
>> >>
>> >>
>> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Royale] Flex to FlexJS migration path

Peter Ent-2
In reply to this post by Idylog - Nicolas Granon
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" <[hidden email]> 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:[hidden email]]
>> Envoyé : samedi 30 septembre 2017 07:56
>> À : [hidden email]; [hidden email]; [hidden email]
>> 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
>> <[hidden email]<mailto:[hidden email]>>
>> Reply-To: "[hidden email]<mailto:[hidden email]>"
>> <[hidden email]<mailto:[hidden email]>>
>> Date: Friday, September 29, 2017 at 5:00 PM
>> To: "[hidden email]<mailto:[hidden email]>"
>> <[hidden email]<mailto:[hidden email]>>,
>> "[hidden email]<mailto:[hidden email]>"
>> <[hidden email]<mailto:[hidden email]>>,
>> "[hidden email]<mailto:[hidden email]>"
>> <[hidden email]<mailto:[hidden email]>>
>> 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
>> <[hidden email]<mailto:[hidden email]>> 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"
>> <[hidden email]<mailto:[hidden email]>> 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"
>> <[hidden email]<mailto:[hidden email]>> 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:[hidden email]<mailto:[hidden email]>]
>> >>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>> >>> [hidden email]<mailto:[hidden email]>;
>> >>> [hidden email]<mailto:[hidden email]>
>> >>> 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"
>> >>> <[hidden email]<mailto:[hidden email]>>
>> >>> 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:[hidden email]<mailto:[hidden email]
>> >>> >> m>] Envoyé : jeudi 28 septembre 2017 19:08 À :
>> >>> >> [hidden email]<mailto:[hidden email]>
>> >>> >> 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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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
>> >>> >> <[hidden email]<mailto:[hidden email]>>:
>> >>> >>
>> >>> >> > 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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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
>> >>> >
>> >>
>> >>
>> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Royale] Flex to FlexJS migration path

Mark Kessler
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 <[hidden email]> 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" <[hidden email]> 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:[hidden email]]
>>> Envoyé : samedi 30 septembre 2017 07:56
>>> À : [hidden email]; [hidden email]; [hidden email]
>>> 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
>>> <[hidden email]<mailto:[hidden email]>>
>>> Reply-To: "[hidden email]<mailto:[hidden email]>"
>>> <[hidden email]<mailto:[hidden email]>>
>>> Date: Friday, September 29, 2017 at 5:00 PM
>>> To: "[hidden email]<mailto:[hidden email]>"
>>> <[hidden email]<mailto:[hidden email]>>,
>>> "[hidden email]<mailto:[hidden email]>"
>>> <[hidden email]<mailto:[hidden email]>>,
>>> "[hidden email]<mailto:[hidden email]>"
>>> <[hidden email]<mailto:[hidden email]>>
>>> 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
>>> <[hidden email]<mailto:[hidden email]>> 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"
>>> <[hidden email]<mailto:[hidden email]>> 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"
>>> <[hidden email]<mailto:[hidden email]>> 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:[hidden email]<mailto:[hidden email]>]
>>> >>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>>> >>> [hidden email]<mailto:[hidden email]>;
>>> >>> [hidden email]<mailto:[hidden email]>
>>> >>> 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"
>>> >>> <[hidden email]<mailto:[hidden email]>>
>>> >>> 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:[hidden email]<mailto:[hidden email]
>>> >>> >> m>] Envoyé : jeudi 28 septembre 2017 19:08 À :
>>> >>> >> [hidden email]<mailto:[hidden email]>
>>> >>> >> 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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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
>>> >>> >> <[hidden email]<mailto:[hidden email]>>:
>>> >>> >>
>>> >>> >> > 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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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
>>> >>> >
>>> >>
>>> >>
>>> >
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Royale] Flex to FlexJS migration path

Harbs
In reply to this post by Peter Ent-2
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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]>
>>>> 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:[hidden email]]
>>>>>> Envoyé : samedi 30 septembre 2017 07:56
>>>>>> À : [hidden email]; [hidden email]; [hidden email]
>>>>>> 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
>>>>>> <[hidden email]<mailto:[hidden email]>>
>>>>>> Reply-To: "[hidden email]<mailto:[hidden email]>"
>>>>>> <[hidden email]<mailto:[hidden email]>>
>>>>>> Date: Friday, September 29, 2017 at 5:00 PM
>>>>>> To: "[hidden email]<mailto:[hidden email]>"
>>>>>> <[hidden email]<mailto:[hidden email]>>,
>>>>>> "[hidden email]<mailto:[hidden email]>"
>>>>>> <[hidden email]<mailto:[hidden email]>>,
>>>>>> "[hidden email]<mailto:[hidden email]>"
>>>>>> <[hidden email]<mailto:[hidden email]>>
>>>>>> 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
>>>>>> <[hidden email]<mailto:[hidden email]>> 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"
>>>>>> <[hidden email]<mailto:[hidden email]>> 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"
>>>>>> <[hidden email]<mailto:[hidden email]>> 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:[hidden email]<mailto:[hidden email]>]
>>>>>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>>>>>>>>> [hidden email]<mailto:[hidden email]>;
>>>>>>>>> [hidden email]<mailto:[hidden email]>
>>>>>>>>> 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"
>>>>>>>>> <[hidden email]<mailto:[hidden email]>>
>>>>>>>>> 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:[hidden email]<mailto:[hidden email]
>>>>>>>>>>> m>] Envoyé : jeudi 28 septembre 2017 19:08 À :
>>>>>>>>>>> [hidden email]<mailto:[hidden email]>
>>>>>>>>>>> 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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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
>>>>>>>>>>> <[hidden email]<mailto:[hidden email]>>:
>>>>>>>>>>>
>>>>>>>>>>>> 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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: [Royale] Flex to FlexJS migration path

Alex Harui-2
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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]>
>>>>> 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:[hidden email]]
>>>>>>> Envoyé : samedi 30 septembre 2017 07:56
>>>>>>> À : [hidden email]; [hidden email];
>>>>>>>[hidden email]
>>>>>>> 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
>>>>>>> <[hidden email]<mailto:[hidden email]>>
>>>>>>> Reply-To: "[hidden email]<mailto:[hidden email]>"
>>>>>>> <[hidden email]<mailto:[hidden email]>>
>>>>>>> Date: Friday, September 29, 2017 at 5:00 PM
>>>>>>> To: "[hidden email]<mailto:[hidden email]>"
>>>>>>> <[hidden email]<mailto:[hidden email]>>,
>>>>>>> "[hidden email]<mailto:[hidden email]>"
>>>>>>> <[hidden email]<mailto:[hidden email]>>,
>>>>>>> "[hidden email]<mailto:[hidden email]>"
>>>>>>> <[hidden email]<mailto:[hidden email]>>
>>>>>>> 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
>>>>>>> <[hidden email]<mailto:[hidden email]>> 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"
>>>>>>> <[hidden email]<mailto:[hidden email]>> 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"
>>>>>>> <[hidden email]<mailto:[hidden email]>> 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:[hidden email]<mailto:[hidden email]>
>>>>>>>>>>]
>>>>>>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>>>>>>>>>> [hidden email]<mailto:[hidden email]>;
>>>>>>>>>> [hidden email]<mailto:[hidden email]>
>>>>>>>>>> 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"
>>>>>>>>>> <[hidden email]<mailto:[hidden email]>>
>>>>>>>>>> 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:[hidden email]<mailto:[hidden email]
>>>>>>>>>>>> m>] Envoyé : jeudi 28 septembre 2017 19:08 À :
>>>>>>>>>>>> [hidden email]<mailto:[hidden email]>
>>>>>>>>>>>> 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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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
>>>>>>>>>>>> <[hidden email]<mailto:[hidden email]>>:
>>>>>>>>>>>>
>>>>>>>>>>>>> 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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Royale] Flex to FlexJS migration path

Carlos Rovira
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 <[hidden email]>:

> 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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]>
> >>>>> 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:[hidden email]]
> >>>>>>> Envoyé : samedi 30 septembre 2017 07:56
> >>>>>>> À : [hidden email]; [hidden email];
> >>>>>>>[hidden email]
> >>>>>>> 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
> >>>>>>> <[hidden email]<mailto:[hidden email]>>
> >>>>>>> Reply-To: "[hidden email]<mailto:[hidden email]
> >"
> >>>>>>> <[hidden email]<mailto:[hidden email]>>
> >>>>>>> Date: Friday, September 29, 2017 at 5:00 PM
> >>>>>>> To: "[hidden email]<mailto:[hidden email]>"
> >>>>>>> <[hidden email]<mailto:[hidden email]>>,
> >>>>>>> "[hidden email]<mailto:[hidden email]>"
> >>>>>>> <[hidden email]<mailto:[hidden email]>>,
> >>>>>>> "[hidden email]<mailto:[hidden email]>"
> >>>>>>> <[hidden email]<mailto:[hidden email]>>
> >>>>>>> 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
> >>>>>>> <[hidden email]<mailto:[hidden email]>> 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"
> >>>>>>> <[hidden email]<mailto:[hidden email]>> 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"
> >>>>>>> <[hidden email]<mailto:[hidden email]>> 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:[hidden email]<mailto:[hidden email]
> >
> >>>>>>>>>>]
> >>>>>>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À :
> >>>>>>>>>> [hidden email]<mailto:[hidden email]>;
> >>>>>>>>>> [hidden email]<mailto:[hidden email]>
> >>>>>>>>>> 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"
> >>>>>>>>>> <[hidden email]<mailto:[hidden email]>>
> >>>>>>>>>> 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:[hidden email]<mailto:[hidden email]
> >>>>>>>>>>>> m>] Envoyé : jeudi 28 septembre 2017 19:08 À :
> >>>>>>>>>>>> [hidden email]<mailto:[hidden email]>
> >>>>>>>>>>>> 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
> >>>>>>>>>>>> <[hidden email]<mailto:[hidden email]>>:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 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.
Reply | Threaded
Open this post in threaded view
|

Re: [Royale] Flex to FlexJS migration path

Peter Ent-2
In reply to this post by Alex Harui-2
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" <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]>
>>>>>> 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:[hidden email]]
>>>>>>>> Envoyé : samedi 30 septembre 2017 07:56
>>>>>>>> À : [hidden email]; [hidden email];
>>>>>>>>[hidden email]
>>>>>>>> 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
>>>>>>>> <[hidden email]<mailto:[hidden email]>>
>>>>>>>> Reply-To:
>>>>>>>>"[hidden email]<mailto:[hidden email]>"
>>>>>>>> <[hidden email]<mailto:[hidden email]>>
>>>>>>>> Date: Friday, September 29, 2017 at 5:00 PM
>>>>>>>> To: "[hidden email]<mailto:[hidden email]>"
>>>>>>>> <[hidden email]<mailto:[hidden email]>>,
>>>>>>>> "[hidden email]<mailto:[hidden email]>"
>>>>>>>> <[hidden email]<mailto:[hidden email]>>,
>>>>>>>> "[hidden email]<mailto:[hidden email]>"
>>>>>>>> <[hidden email]<mailto:[hidden email]>>
>>>>>>>> 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
>>>>>>>> <[hidden email]<mailto:[hidden email]>> 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"
>>>>>>>> <[hidden email]<mailto:[hidden email]>> 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"
>>>>>>>> <[hidden email]<mailto:[hidden email]>> 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:[hidden email]<mailto:[hidden email]
>>>>>>>>>>>>
>>>>>>>>>>>]
>>>>>>>>>>> Envoyé : jeudi 28 septembre 2017 22:32 À :
>>>>>>>>>>> [hidden email]<mailto:[hidden email]>;
>>>>>>>>>>> [hidden email]<mailto:[hidden email]>
>>>>>>>>>>> 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"
>>>>>>>>>>> <[hidden email]<mailto:[hidden email]>>
>>>>>>>>>>> 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:[hidden email]<mailto:[hidden email]
>>>>>>>>>>>>> m>] Envoyé : jeudi 28 septembre 2017 19:08 À :
>>>>>>>>>>>>> [hidden email]<mailto:[hidden email]>
>>>>>>>>>>>>> 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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%">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
>>>>>>>>>>>>> <[hidden email]<mailto:[hidden email]>>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%">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<<a href="https://na01.safelinks.protection.outlook.com/?url=http%3">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
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>><<a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2">https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>>>>>>F
>>>>>>>>>>pl.
>>>>>>>>>>> l
>>>>>>>>>>>>> ink
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>edin.com<<a href="https://na01.safelinks.protection.outlook.com/?url=http%">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
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>