[FlexJS] Guidelines for implementation of layout containers and navigation containers

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

[FlexJS] Guidelines for implementation of layout containers and navigation containers

Idylog - Nicolas Granon
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://cwiki.apache.org/confluence/display/FLEX/Creating+Components 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




Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Guidelines for implementation of layout containers and navigation containers

piotrz
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://cwiki.apache.org/confluence/display/FLEX/FlexJS+Container+Classes+and+Layouts
[2] https://github.com/apache/royale-asjs/tree/develop/examples/flexjs
[3]
https://github.com/apache/royale-asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apache/flex/html
[4]
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=71013028
[5]
https://github.com/apache/royale-asjs/tree/develop/frameworks/projects/MaterialDesignLite/src/main/flex/org/apache/flex/mdl
[6]
https://github.com/apache/royale-asjs/tree/develop/examples/flexjs/MDLExample
[7] https://getmdl.io/components/index.html
[8] https://cwiki.apache.org/confluence/display/FLEX/Table+Of+Components

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://cwiki.apache.org/confluence/display/FLEX/Creating+Components 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: http://www.linkedin.com/piotrzarzycki
<https://pl.linkedin.com/in/piotr-zarzycki-92a53552>

GitHub: https://github.com/piotrzarzycki21
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Guidelines for implementation of layout containers and navigation containers

Peter Ent-2
Check the Mobile project - there are tab and view stack navigators there.
There is also the MobileTrader example that uses them. They are sort-of
iOS oriented since that's what I'm more familiar with. We may need to
re-do these or have alternatives.

For layouts, there is also
https://cwiki.apache.org/confluence/display/FLEX/FlexJS+Layout

‹peter

On 9/28/17, 1:07 PM, "Piotr Zarzycki" <[hidden email]> wrote:

>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%2Fcwiki.apa
>che.org%2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClasses%2Band
>%2BLayouts&data=02%7C01%7C%7Ce5dcc3bc16254ffe7b5908d506936eef%7Cfa7b1b5a7b
>34438794aed2c178decee1%7C0%7C0%7C636422152677765093&sdata=eB31XB%2B5jt4bjr
>kZom9TbpkyoIOWZa9DnPXSLdEOy54%3D&reserved=0
>[2]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>m%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs&data=02%7C01
>%7C%7Ce5dcc3bc16254ffe7b5908d506936eef%7Cfa7b1b5a7b34438794aed2c178decee1%
>7C0%7C0%7C636422152677765093&sdata=pG0%2BZ6pIwxeb9TA%2Fg6enSFhXj%2Fz5M6GmU
>BexB21VDFs%3D&reserved=0
>[3]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>m%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fframeworks%2Fprojects%2FBasic%
>2Fsrc%2Fmain%2Fflex%2Forg%2Fapache%2Fflex%2Fhtml&data=02%7C01%7C%7Ce5dcc3b
>c16254ffe7b5908d506936eef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636
>422152677765093&sdata=iN%2F36SoXPgkt%2F6Ts5sKO%2B1JW2lUIkhw4nQetJc4i6%2F4%
>3D&reserved=0
>[4]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apa
>che.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D71013028&data=02
>%7C01%7C%7Ce5dcc3bc16254ffe7b5908d506936eef%7Cfa7b1b5a7b34438794aed2c178de
>cee1%7C0%7C0%7C636422152677765093&sdata=Gt801I2YajwV9zEQWbDt3ql8Ru9iYZA%2F
>tenzF5l3ygs%3D&reserved=0
>[5]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>m%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fframeworks%2Fprojects%2FMateri
>alDesignLite%2Fsrc%2Fmain%2Fflex%2Forg%2Fapache%2Fflex%2Fmdl&data=02%7C01%
>7C%7Ce5dcc3bc16254ffe7b5908d506936eef%7Cfa7b1b5a7b34438794aed2c178decee1%7
>C0%7C0%7C636422152677765093&sdata=lzyD34EFykiTkbT0LMuscyq9JXYjfXXImqq7IPqZ
>Ywg%3D&reserved=0
>[6]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>m%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs%2FMDLExample
>&data=02%7C01%7C%7Ce5dcc3bc16254ffe7b5908d506936eef%7Cfa7b1b5a7b34438794ae
>d2c178decee1%7C0%7C0%7C636422152677765093&sdata=BunX2AglKjbltW2POdrQFY9Cux
>ZWokwQeb8fAb5%2FgUI%3D&reserved=0
>[7]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgetmdl.io
>%2Fcomponents%2Findex.html&data=02%7C01%7C%7Ce5dcc3bc16254ffe7b5908d506936
>eef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422152677765093&sdata=
>bVjUrkXoe4u1vkossvp844GERrbfHn3VJgacRm4mIDE%3D&reserved=0
>[8]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apa
>che.org%2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data=02%7C
>01%7C%7Ce5dcc3bc16254ffe7b5908d506936eef%7Cfa7b1b5a7b34438794aed2c178decee
>1%7C0%7C0%7C636422152677765093&sdata=Xe9Nunps2jBV4v9z%2BkLFyJunSdHSDYt76jG
>c%2BjY1whs%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%2Fcwiki.ap
>>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=02%7C
>>01%7C%7Ce5dcc3bc16254ffe7b5908d506936eef%7Cfa7b1b5a7b34438794aed2c178dece
>>e1%7C0%7C0%7C636422152677765093&sdata=YQ2T0%2FTyeOsyDtuMiogEIm00v0yGj6gOd
>>MHpqDWn9yY%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.linked
>in.com%2Fpiotrzarzycki&data=02%7C01%7C%7Ce5dcc3bc16254ffe7b5908d506936eef%
>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422152677765093&sdata=nqBu
>EvEeyYpZdhZAg7hsEP0O4N1Xd0gG3qQP7MKZP%2BA%3D&reserved=0
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpl.linke
>din.com%2Fin%2Fpiotr-zarzycki-92a53552&data=02%7C01%7C%7Ce5dcc3bc16254ffe7
>b5908d506936eef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364221526777
>65093&sdata=3THr%2B70zEybrm5d6eOg05sF9L0ycReIul4eA6ibtCYI%3D&reserved=0>
>
>GitHub:
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>m%2Fpiotrzarzycki21&data=02%7C01%7C%7Ce5dcc3bc16254ffe7b5908d506936eef%7Cf
>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422152677765093&sdata=vmw%2BJ
>toHnT3pqGCb2Oni2XVqMY9nX35lu8Rz9lKkQtU%3D&reserved=0

Reply | Threaded
Open this post in threaded view
|

RE: [FlexJS] Guidelines for implementation of layout containers and navigation containers

Idylog - Nicolas Granon
In reply to this post by piotrz
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://cwiki.apache.org/confluence/display/FLEX/FlexJS+Container+Class
> es+and+Layouts
> [2] https://github.com/apache/royale-asjs/tree/develop/examples/flexjs
> [3]
> https://github.com/apache/royale-
> asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apache/fl
> ex/html
> [4]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=710130
> 28
> [5]
> https://github.com/apache/royale-
> asjs/tree/develop/frameworks/projects/MaterialDesignLite/src/main/flex/
> org/apache/flex/mdl
> [6]
> https://github.com/apache/royale-
> asjs/tree/develop/examples/flexjs/MDLExample
> [7] https://getmdl.io/components/index.html
> [8]
> https://cwiki.apache.org/confluence/display/FLEX/Table+Of+Components
>
> 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://cwiki.apache.org/confluence/display/FLEX/Creating+Components
> > 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: http://www.linkedin.com/piotrzarzycki
> <https://pl.linkedin.com/in/piotr-zarzycki-92a53552>
>
> GitHub: https://github.com/piotrzarzycki21

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Guidelines for implementation of layout containers and navigation containers

piotrz
Nicolas,

Fully understand your needs. Thanks for a deeper explanation. One of the
things which you can get out of the box is for sure that your business
logic free from Flash dependency in your app can be just used. Compiler
should nicely consume it and give you an JS.

The problem with FlexJS is that once someone is touching it he expects that
it will be working as good as Flex, but the true is that we have still a
lot of job to do and framework is in beta state. It means that we sometimes
need helps from someone who have deeper knowledge what is under the mask of
our car. I hope our project split which is ongoing help us to be better in
terms of documentation, usability and decrease those problems or even
eliminate it.

Feel free ask any specific questions once you start building something
maybe we will be able to help you enough fast to get your job forward.

Piotr


2017-09-28 21:43 GMT+02:00 Idylog - Nicolas Granon <[hidden email]>:

> 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://cwiki.apache.org/confluence/display/FLEX/FlexJS+Container+Class
> > es+and+Layouts
> > [2] https://github.com/apache/royale-asjs/tree/develop/examples/flexjs
> > [3]
> > https://github.com/apache/royale-
> > asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apache/fl
> > ex/html
> > [4]
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=710130
> > 28
> > [5]
> > https://github.com/apache/royale-
> > asjs/tree/develop/frameworks/projects/MaterialDesignLite/src/main/flex/
> > org/apache/flex/mdl
> > [6]
> > https://github.com/apache/royale-
> > asjs/tree/develop/examples/flexjs/MDLExample
> > [7] https://getmdl.io/components/index.html
> > [8]
> > https://cwiki.apache.org/confluence/display/FLEX/Table+Of+Components
> >
> > 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://cwiki.apache.org/confluence/display/FLEX/Creating+Components
> > > 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: http://www.linkedin.com/piotrzarzycki
> > <https://pl.linkedin.com/in/piotr-zarzycki-92a53552>
> >
> > GitHub: https://github.com/piotrzarzycki21
>
>


--

Piotr Zarzycki

mobile: +48 880 859 557
skype: zarzycki10

LinkedIn: http://www.linkedin.com/piotrzarzycki
<https://pl.linkedin.com/in/piotr-zarzycki-92a53552>

GitHub: https://github.com/piotrzarzycki21
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Guidelines for implementation of layout containers and navigation containers

Alex Harui-2
In reply to this post by Idylog - Nicolas Granon
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%2Fcwiki.ap
>>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS%2BContainer%2BClass&data=
>>02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c17
>>8decee1%7C0%7C0%7C636422245942183624&sdata=yA85mg2rRcco0Vi8GBG3Xruu84Aq88
>>7xFTPSj2DuB%2B0%3D&reserved=0
>> es+and+Layouts
>> [2]
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>>om%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fexamples%2Fflexjs&data=02%7C
>>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178dece
>>e1%7C0%7C0%7C636422245942183624&sdata=gkPyRWavwCQn1TPRxlGY2CeJR6MDc%2Bt1Y
>>YMHGPVL7jA%3D&reserved=0
>> [3]
>>
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>>om%2Fapache%2Froyale-&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%
>>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=xB2
>>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>> asjs/tree/develop/frameworks/projects/Basic/src/main/flex/org/apache/fl
>> ex/html
>> [4]
>>
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.ap
>>ache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D710130&data=02
>>%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178d
>>ecee1%7C0%7C0%7C636422245942183624&sdata=KfoKzSCU5HYXDl492BvyU7a8lQTzL8KG
>>N7kM0uCu2z4%3D&reserved=0
>> 28
>> [5]
>>
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>>om%2Fapache%2Froyale-&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%
>>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=xB2
>>5CrfMRtSEC4db618sIQL%2Bv4aSGRjiMtzCPMiO4Ho%3D&reserved=0
>> asjs/tree/develop/frameworks/projects/MaterialDesignLite/src/main/flex/
>> org/apache/flex/mdl
>> [6]
>>
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>>om%2Fapache%2Froyale-&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%
>>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%2Fgetmdl.i
>>o%2Fcomponents%2Findex.html&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a
>>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%2Fcwiki.ap
>>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FTable%2BOf%2BComponents&data=02%
>>7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178de
>>cee1%7C0%7C0%7C636422245942183624&sdata=3SIhtWuyCCsN%2BrbP8C7xRtJrdXnDLai
>>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%2Fcwiki.ap
>>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=02%7C
>>01%7C%7Cab4e20a981d44a9ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178dece
>>e1%7C0%7C0%7C636422245942183624&sdata=eSUv4Bg4Ng7VafkTTbVk1lZoLzLHc8vutx5
>>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.linke
>>din.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a9268
>>8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=S
>>ggb%2FVIn%2B0dBskPJ%2BZfJtXnRRrATLh1SHlamyGV58zM%3D&reserved=0
>>
>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpl.link
>>edin.com%2Fin%2Fpiotr-zarzycki-92a53552&data=02%7C01%7C%7Cab4e20a981d44a9
>>ea01408d506a92688%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364222459
>>42183624&sdata=tSGDWZ5AhBPECbf1%2Fy9R2u9N4qwJ03VBhzwzNsPTcCM%3D&reserved=
>>0>
>>
>> GitHub:
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>>om%2Fpiotrzarzycki21&data=02%7C01%7C%7Cab4e20a981d44a9ea01408d506a92688%7
>>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636422245942183624&sdata=lMum
>>yqy%2BFrMov66HlNTEAg1eIymQuVPlyd0%2FCWNT%2B6s%3D&reserved=0
>

Reply | Threaded
Open this post in threaded view
|

RE: [FlexJS] Flex to FlexJS migration path

Idylog - Nicolas Granon
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: [FlexJS] Guidelines for implementation of layout containers and navigation containers

Harbs
In reply to this post by Idylog - Nicolas Granon
Let’s continue this discussion on the Royale dev list if possible.

I just implemented the first iteration of Validation. The implementation was taken almost verbatim from the old Flex implementation. You can follow the process of porting the code in the branch here. It should be educational.

https://github.com/apache/royale-asjs/tree/feature/validation <https://github.com/apache/royale-asjs/tree/feature/validation>

Additionally I wrote some notes on the process (which is not yet finished) in this Google Doc here. It notes differences in classic Flex architecture and the new FlexJS/Royale architecture and why a direct port is not desirable.
https://docs.google.com/document/d/1HBh3jrYKtyGYM14wNGkMhqP0zF_O8c0iuaEeZmb3veE/edit?usp=sharing <https://docs.google.com/document/d/1HBh3jrYKtyGYM14wNGkMhqP0zF_O8c0iuaEeZmb3veE/edit?usp=sharing>

I hope it’s helpful in understanding how things are done. If you want to get you hands dirty, we’re happy to help. :-)

Implementing ResourceManager will probably have related considerations. Do you need to switch locales at runtime or do you just need to be able to specify a locale? A lot of the Flex implementation of ResourceManager was designed to deal with the former. I think the vast majority of uses probably only need the latter. These are all things which need to be considered.

Thanks,
Harbs

> On Sep 28, 2017, at 10:43 PM, Idylog - Nicolas Granon <[hidden email]> wrote:
>
> 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).

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Guidelines for implementation of layout containers and navigation containers

Harbs
In reply to this post by Idylog - Nicolas Granon
I just want to comment on this:

I expect most users to not care about swf output. However, on the framework level it’s important for a number of reasons:
1. Runtime type checking. Running the code through the Flash runtime has value even if it’s never used in production. It offers additional checks which cannot be caught by any of the compilers. This is a feature built into Flash which is not apparent until it finds bugs.
2. Support for AIR. Being able to target JS and AIR is going to be valuable to some folks.
3. It makes sure we develop with more than one target in mind. To me this is the strongest reason. Eventually we are probably going to want to target native on iOS, Android, etc. If the framework is designed to target both JS and Flash, it forces us to abstract things enough to be applicable to two very different rendering engines. Adding a third and forth target once it’s designed like that is much easier. There has already been talk about support WebASM and the like, and the idea of truly native output has come up as well. If you question the value of that, take a look at React Native. Without being forced to have a second target it’s way too easy to resort to just thinly wrapping web APIs without giving thought to abstracting them enough to make the classes applicable to other environments.

I hope this clarifies the mindset a bit…

Thanks,
Harbs

> On Sep 28, 2017, at 10:43 PM, Idylog - Nicolas Granon <[hidden email]> wrote:
>
> 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).

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] Guidelines for implementation of layout containers and navigation containers

Mark Kessler
+1 and all 3 points.

The power of the current flex SDK is based on the fact it can target
multiple things with one code base.  While the browser portion is
clear, meaning Flash to JS, the support for Air is important.  Air can
easily do desktop and mobile.


-Mark K

On Sat, Sep 30, 2017 at 10:29 PM, Harbs <[hidden email]> wrote:

> I just want to comment on this:
>
> I expect most users to not care about swf output. However, on the framework
> level it’s important for a number of reasons:
> 1. Runtime type checking. Running the code through the Flash runtime has
> value even if it’s never used in production. It offers additional checks
> which cannot be caught by any of the compilers. This is a feature built into
> Flash which is not apparent until it finds bugs.
> 2. Support for AIR. Being able to target JS and AIR is going to be valuable
> to some folks.
> 3. It makes sure we develop with more than one target in mind. To me this is
> the strongest reason. Eventually we are probably going to want to target
> native on iOS, Android, etc. If the framework is designed to target both JS
> and Flash, it forces us to abstract things enough to be applicable to two
> very different rendering engines. Adding a third and forth target once it’s
> designed like that is much easier. There has already been talk about support
> WebASM and the like, and the idea of truly native output has come up as
> well. If you question the value of that, take a look at React Native.
> Without being forced to have a second target it’s way too easy to resort to
> just thinly wrapping web APIs without giving thought to abstracting them
> enough to make the classes applicable to other environments.
>
> I hope this clarifies the mindset a bit…
>
> Thanks,
> Harbs
>