Re: [FlexJS] Some things still missing ni FlexJS

[Alex Harui]

On 1/18/17, 5:11 AM, "Kessler CTR Mark J" 
wrote:
>
>Could we have a new namespace of AS components that are stripped down
>that are 100% compatible to the FlexJS side?   People could start
>converting over existing apps slowly while still being able to deploy to
>their current targets.  Could also allow a bit more decoupling from the
>core player AS.  I would find this more interesting of an avenue.

Not quite sure what you mean here.  It is hard to hide APIs so I think it
is hard to truly strip down.  But the Spark-ish component set I mentioned
should do what I think you want.  The JS SWCs won't have the Flash APIs.
But it needs someone to make it happen.

-Alex

RE: [FlexJS] Some things still missing ni FlexJS

[Kessler CTR Mark J]

1.   Luckily we are not under any deadline at this time, but we did get a zing 
from a code review we had.  They recommended we should migrate at some point.  
However our branch is always behind the industry curve for certain things.  For 
instance we have a large population of Win7 users still.

2.  It would be based on perspective, luckily we use most of the common 
components and charts.  90% could be acceptable for conversion.  This is of 
course removing any customization to components from the equation.  Those will 
always require a change.

3.  I might here and there, but I've received a few new people that are 
consuming additional time getting them up to speed.   Causing me to catch up on 
work.


I like the idea of your comparison list.  It would be a large table, but very 
functional.

Could we have a new namespace of AS components that are stripped down that are 
100% compatible to the FlexJS side?   People could start converting over 
existing apps slowly while still being able to deploy to their current targets. 
 Could also allow a bit more decoupling from the core player AS.  I would find 
this more interesting of an avenue.


-Mark



-Original Message-
From: Alex Harui [mailto:aha...@adobe.com]
Sent: Tuesday, January 17, 2017 4:29 PM
To: dev@flex.apache.org
Subject: [Non-DoD Source] Re: [FlexJS] Some things still missing ni FlexJS



On 1/17/17, 3:43 AM, "Kessler CTR Mark J" <mark.kessler@usmc.mil>
wrote:

>I do not use AMF for enterprise level applications.  AMF falls short
>of our requirements.  But the bottom line for us for converting to FlexJS
>would be seamless operation(look / feel / interaction) in all major
>browsers (excluding IE) and the ability to compile it using our existing
>spark based projects without having to having to create hundreds of JS
>beads / customizations.  Understandably heavier, but compatibility is
>more important.
>
>The only selling point to me for converting to FlexJS would be that I
>could cross compile Adobe Air apps and FlexJS.  If not, then it would be
>creating everything from scratch again.   If that's the case I would have
>to consider all the available SDK's out there before making a decision.

Thanks for posting this.  Some questions:

1) Are you under any deadline to migrate off of Flash?
2) If it turned out that 80% or 90% of your code would cross-compile would
you still consider a full port to other SDKs?  I doubt we'll ever get to
100%.
3) Would you have time to help get us to 80% or 90% or 99.5%?

This got me thinking about whether Falcon could easily be tweaked to
output a list of all APIs used by a code base.  Then we could see how much
of the Flex SDK and Flash APIs and other third-party APIs someone was
using.  It turns out that Spark Button has about 120 public APIs!  It will
be awhile if ever before FlexJS reproduces all 120.  But my bet is that
most of you only use about 12 APIs.  While we have the Express set, and
I've shown that porting most of Spark and MX on top of UIBase is
"possible", in between there is the possibility of a "Spark-ish" set that
builds on top of Basic like Express did and only supports the 12 popular
Spark APIs for Button, etc, eventually adds a few more, but never promises
to do all 120.

Thoughts?
-Alex

Re: [FlexJS] Some things still missing ni FlexJS

[Alex Harui]

On 1/17/17, 3:43 AM, "Kessler CTR Mark J" 
wrote:

>I do not use AMF for enterprise level applications.  AMF falls short
>of our requirements.  But the bottom line for us for converting to FlexJS
>would be seamless operation(look / feel / interaction) in all major
>browsers (excluding IE) and the ability to compile it using our existing
>spark based projects without having to having to create hundreds of JS
>beads / customizations.  Understandably heavier, but compatibility is
>more important.
>
>The only selling point to me for converting to FlexJS would be that I
>could cross compile Adobe Air apps and FlexJS.  If not, then it would be
>creating everything from scratch again.   If that's the case I would have
>to consider all the available SDK's out there before making a decision.

Thanks for posting this.  Some questions:

1) Are you under any deadline to migrate off of Flash?
2) If it turned out that 80% or 90% of your code would cross-compile would
you still consider a full port to other SDKs?  I doubt we'll ever get to
100%.
3) Would you have time to help get us to 80% or 90% or 99.5%?

This got me thinking about whether Falcon could easily be tweaked to
output a list of all APIs used by a code base.  Then we could see how much
of the Flex SDK and Flash APIs and other third-party APIs someone was
using.  It turns out that Spark Button has about 120 public APIs!  It will
be awhile if ever before FlexJS reproduces all 120.  But my bet is that
most of you only use about 12 APIs.  While we have the Express set, and
I've shown that porting most of Spark and MX on top of UIBase is
"possible", in between there is the possibility of a "Spark-ish" set that
builds on top of Basic like Express did and only supports the 12 popular
Spark APIs for Button, etc, eventually adds a few more, but never promises
to do all 120.

Thoughts?
-Alex

Re: [FlexJS] Some things still missing ni FlexJS

[Peter Ent]

See comment in-line.
‹peter

On 1/17/17, 9:11 AM, "yishayw"  wrote:

>Kessler CTR Mark J wrote
>> the ability to compile it using our existing spark based projects
>>without
>> having to having to create hundreds of JS beads / customizations.
>> Understandably heavier, but compatibility is more important.
>
>An effort is underway to create a component set that bakes in more beads
>and
>reduces code verbosity. I don't think you can expect complete backwards
>compatibility anytime soon though.

This effort is the Express package (org.apache.flex.express). There is an
example in examples/express. I will try to add more as time goes on.

> 
>
>When migrating, one thing you can do that will help you reduce
>customization
>is to create your own app specific component set that bakes in the beads
>you
>actually use. Then you can replace Spark components with your own
>components
>and the code ends up looking quite similar to what it was.
>
>
>Kessler CTR Mark J wrote
>> The only selling point to me for converting to FlexJS would be that
>>I
>> could cross compile Adobe Air apps and FlexJS.
>
>Out of curiosity, do you mean cross compiling specifically to Adobe AIR,
>as
>opposed to, for example, Cordova?
>
>
>
>
>--
>View this message in context:
>http://apache-flex-development.247.n4.nabble.com/FlexJS-Some-things-st
>ill-missing-ni-FlexJS-tp57985p58395.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

RE: [FlexJS] Some things still missing ni FlexJS

[yishayw]

Kessler CTR Mark J wrote
> the ability to compile it using our existing spark based projects without
> having to having to create hundreds of JS beads / customizations. 
> Understandably heavier, but compatibility is more important.

An effort is underway to create a component set that bakes in more beads and
reduces code verbosity. I don't think you can expect complete backwards
compatibility anytime soon though. 

When migrating, one thing you can do that will help you reduce customization
is to create your own app specific component set that bakes in the beads you
actually use. Then you can replace Spark components with your own components
and the code ends up looking quite similar to what it was.


Kessler CTR Mark J wrote
> The only selling point to me for converting to FlexJS would be that I
> could cross compile Adobe Air apps and FlexJS.

Out of curiosity, do you mean cross compiling specifically to Adobe AIR, as
opposed to, for example, Cordova?




--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Some-things-still-missing-ni-FlexJS-tp57985p58395.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

RE: [FlexJS] Some things still missing ni FlexJS

[Kessler CTR Mark J]

I do not use AMF for enterprise level applications.  AMF falls short of our 
requirements.  But the bottom line for us for converting to FlexJS would be 
seamless operation(look / feel / interaction) in all major browsers (excluding 
IE) and the ability to compile it using our existing spark based projects 
without having to having to create hundreds of JS beads / customizations.  
Understandably heavier, but compatibility is more important.

The only selling point to me for converting to FlexJS would be that I could 
cross compile Adobe Air apps and FlexJS.  If not, then it would be creating 
everything from scratch again.   If that's the case I would have to consider 
all the available SDK's out there before making a decision.


-Mark

-Original Message-
From: Alex Harui [mailto:aha...@adobe.com]
Sent: Friday, January 13, 2017 1:11 PM
To: dev@flex.apache.org
Subject: [Non-DoD Source] Re: [FlexJS] Some things still missing ni FlexJS



On 1/13/17, 12:44 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:

>Well from my point of view it was the whole “write once run everywhere”
>thing.
>I was totally annoyed of having to write UI things once and then patch
>and bugfix things for all the other Browsers.

I would say that fits under the "Developer Productivity" umbrella.

>
>But in general I think you (Alex) and I have one great difference in our
>assumption of who will probably be our generation 1 users.
>
>You assume it’s mainly the people wanting to create new applications.
>That’s why you see 1.0 the way you do it.

That is an incorrect assumption.

IMO, there are at least some existing Flex apps that don't use AMF.  Now
it may turn out that we will have AMF shortly, but until it is done, those
who don't need it can start migrating their apps today.  Some folks are
already migrating.  I will believe that AMF is used by the vast majority
of Flex apps, but as I said upthread, we simply need to attract more
committers/contributors to really get FlexJS off the ground.  Some folks
believe that declaring something as 1.0 will invite more folks to try it
and thus get involved.  I don't have a strong opinion, but that sounds
like a reasonable approach, and better than telling folks not to try
FlexJS for another year or two and wait for the few of us who are active
committers to reproduce all of these killer features that a much larger
team of full-timers did at Adobe over many more years.

Flex 4 had many more features than Flex 3, which had more features than
Flex 2 which had more features than Flex 1.0.  FlexJS 1.0 may only allow a
small percentage of Flex customers to migrate, but again, if that brings
in new contributors we can handle more Flex customers with FlexJS 2.0 and
so on.

There may also be a way to get traction with new customers and new apps as
well by trying to get attention from Cordova developers, CreateJS
developers, etc.  I don't care who gets to production first, whether it is
a new app or migrated app, but mainly, I think a testimonial is what we
really need since we don't have a budget for marketing.  So when folks
show up with a need in order to get to production, I will try to help them
out.

-Alex

Re: [FlexJS] Some things still missing ni FlexJS

[Alex Harui]

On 1/16/17, 12:45 AM, "Christofer Dutz"  wrote:

>I would strongly object to make the FlexJS Compiler directly utilize
>Cordova. This would tightly couple the two.
>Guess I just don’t understand quite what’s the difference between the
>CordovaCameraExample which produces a Cordova project, which is then
>packaged using cordova in another step.
>I think creating an archetype for this to easily setup a new project is
>definitely a thing that should be done (eventually by myself), but I
>wouldn’t like to see the FlexJS compiler include anything Cordova
>directly.

Not sure what you mean by "include".  I don't think we would add any new
jars to the class path.  But the Publisher part of FalconJX knows certain
things about the output JS already because it has to scan all JS files to
figure out the right goog.requires anyway.  For example the inject_html
"directives" instruct on some of the content of the output HTML file, and
I'm about to commit a change where the publisher scans for @externs in
order to make it much easier to work with third-party libraries by
creating their typedefs in AS.  If a Cordova-specific publisher scanned
for "@cordovaplugin", it might greatly simplify management of Cordova
plugins in Cordova projects.  I think there is already more than one
Publisher like one for Node.

I will say, though, that I've been wondering if the Publisher piece really
belongs in the compiler in the first place.  If there is a more
Maven-friendly way to do it we should definitely try to head in that
direction.  My main thought here is that we are already scanning the JS
and we can leverage that scan to improve developer productivity for
Cordova.  But if we move that scan to something else, then that's where
the Cordova-specific functionality should move as well.  It wouldn't be
good to scan all of the JS twice.

-Alex

Re: [FlexJS] Some things still missing ni FlexJS

[Carlos Rovira]

+1 to Cordova FlexJS Project Archetype (without doubt)

2017-01-16 9:45 GMT+01:00 Christofer Dutz :

> I would strongly object to make the FlexJS Compiler directly utilize
> Cordova. This would tightly couple the two.
> Guess I just don’t understand quite what’s the difference between the
> CordovaCameraExample which produces a Cordova project, which is then
> packaged using cordova in another step.
> I think creating an archetype for this to easily setup a new project is
> definitely a thing that should be done (eventually by myself), but I
> wouldn’t like to see the FlexJS compiler include anything Cordova directly.
>
> Chris
>
>
> Am 16.01.17, 07:36 schrieb "Alex Harui" :
>
>
>
> On 1/15/17, 9:12 AM, "Christofer Dutz" 
> wrote:
>
> >What exactly are you talking about when mentioning “Cordova Support”?
> >Don’t we already have examples that are bundled with Cordova to valid
> >Mobile Apps?
> >What’s missing here?
>
> Not sure I understand you question, but in another thread I mentioned
> having a Cordova-specific "Publisher".  It would know how to create a
> Cordova Project in the output folder if it didn't already exist,
> automatically add Cordova plugins that are represented by SWCs in the
> library-path, maybe more.
>
> If Flex became the preferred way or even a recommended way of building
> Cordova apps, having big name companies marketing for us would be a
> huge
> win.
>
> Of course, I could be wrong...
> -Alex
>
>
>
>


-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS] Some things still missing ni FlexJS

[Christofer Dutz]

I would strongly object to make the FlexJS Compiler directly utilize Cordova. 
This would tightly couple the two. 
Guess I just don’t understand quite what’s the difference between the 
CordovaCameraExample which produces a Cordova project, which is then packaged 
using cordova in another step.
I think creating an archetype for this to easily setup a new project is 
definitely a thing that should be done (eventually by myself), but I wouldn’t 
like to see the FlexJS compiler include anything Cordova directly.

Chris


Am 16.01.17, 07:36 schrieb "Alex Harui" :



On 1/15/17, 9:12 AM, "Christofer Dutz"  wrote:

>What exactly are you talking about when mentioning “Cordova Support”?
>Don’t we already have examples that are bundled with Cordova to valid
>Mobile Apps?
>What’s missing here?

Not sure I understand you question, but in another thread I mentioned
having a Cordova-specific "Publisher".  It would know how to create a
Cordova Project in the output folder if it didn't already exist,
automatically add Cordova plugins that are represented by SWCs in the
library-path, maybe more.

If Flex became the preferred way or even a recommended way of building
Cordova apps, having big name companies marketing for us would be a huge
win.

Of course, I could be wrong...
-Alex

Re: [FlexJS] Some things still missing ni FlexJS

[Alex Harui]

On 1/15/17, 9:12 AM, "Christofer Dutz"  wrote:

>What exactly are you talking about when mentioning “Cordova Support”?
>Don’t we already have examples that are bundled with Cordova to valid
>Mobile Apps?
>What’s missing here?

Not sure I understand you question, but in another thread I mentioned
having a Cordova-specific "Publisher".  It would know how to create a
Cordova Project in the output folder if it didn't already exist,
automatically add Cordova plugins that are represented by SWCs in the
library-path, maybe more.

If Flex became the preferred way or even a recommended way of building
Cordova apps, having big name companies marketing for us would be a huge
win.

Of course, I could be wrong...
-Alex

Re: [FlexJS] Some things still missing ni FlexJS

[Christofer Dutz]

What exactly are you talking about when mentioning “Cordova Support”? Don’t we 
already have examples that are bundled with Cordova to valid Mobile Apps?
What’s missing here?

Chris

Am 15.01.17, 07:58 schrieb "Alex Harui" :



On 1/14/17, 4:00 AM, "Vincent"  wrote:

>So what would be the interest of choosing technologies like Cordova
>instead of AIR to generate cross platform mobile apps ?

A goal of Apache projects is to do their best to be independent of
corporate influence.  Flex is at Apache because a corporation made a big
change that impacted a lot of people.  There are no signs of any big
changes around AIR, but the future of Apache Flex is better guaranteed by
not counting on a proprietary runtime for a major target market.  I think
FlexJS should support mobile apps, and thus Cordova is a good first
choice.  It doesn't have to be the only one.

In fact, a JIRA issue was just filed to request that we produce a FlexJS
release that has no Adobe dependencies.  I think we can actually do that
now.  Volunteers are needed to make this happen.

Technically, a Cordova app should result in a smaller download than an app
that bundles the entire AIR runtime.  That was important to folks at one
point.  Don't know if it still is.  And a Cordova app can theoretically
run in more places than AIR:  Windows Phone was asked about often at one
point.  Not sure if it is important anymore.

Finally, Adobe (and I think MS, IBM, and other big names) seem to be
continuing to push Cordova.  Aligning FlexJS as the faster way to learn
and use Cordova could bring us much needed resources, attention and
credibility in the enterprise.  I will admit I never shopped for an
alternative to Cordova since Cordova being at Apache made it a no-brainer
for me, but if there are alternatives, we can certainly work with them as
well.

Of course, I could be wrong...
-Alex

Re: [FlexJS] Some things still missing ni FlexJS

[Vincent]

Hi Alex,

I wasn't thinking from a strategical point of view but only from a 
technical one.

That make sense.

Thank you.

Vincent



Le 15/01/2017 à 07:58, Alex Harui a écrit :


On 1/14/17, 4:00 AM, "Vincent"  wrote:


So what would be the interest of choosing technologies like Cordova
instead of AIR to generate cross platform mobile apps ?

A goal of Apache projects is to do their best to be independent of
corporate influence.  Flex is at Apache because a corporation made a big
change that impacted a lot of people.  There are no signs of any big
changes around AIR, but the future of Apache Flex is better guaranteed by
not counting on a proprietary runtime for a major target market.  I think
FlexJS should support mobile apps, and thus Cordova is a good first
choice.  It doesn't have to be the only one.

In fact, a JIRA issue was just filed to request that we produce a FlexJS
release that has no Adobe dependencies.  I think we can actually do that
now.  Volunteers are needed to make this happen.

Technically, a Cordova app should result in a smaller download than an app
that bundles the entire AIR runtime.  That was important to folks at one
point.  Don't know if it still is.  And a Cordova app can theoretically
run in more places than AIR:  Windows Phone was asked about often at one
point.  Not sure if it is important anymore.

Finally, Adobe (and I think MS, IBM, and other big names) seem to be
continuing to push Cordova.  Aligning FlexJS as the faster way to learn
and use Cordova could bring us much needed resources, attention and
credibility in the enterprise.  I will admit I never shopped for an
alternative to Cordova since Cordova being at Apache made it a no-brainer
for me, but if there are alternatives, we can certainly work with them as
well.

Of course, I could be wrong...
-Alex

Re: [FlexJS] Some things still missing ni FlexJS

[Alex Harui]

On 1/14/17, 4:00 AM, "Vincent"  wrote:

>So what would be the interest of choosing technologies like Cordova
>instead of AIR to generate cross platform mobile apps ?

A goal of Apache projects is to do their best to be independent of
corporate influence.  Flex is at Apache because a corporation made a big
change that impacted a lot of people.  There are no signs of any big
changes around AIR, but the future of Apache Flex is better guaranteed by
not counting on a proprietary runtime for a major target market.  I think
FlexJS should support mobile apps, and thus Cordova is a good first
choice.  It doesn't have to be the only one.

In fact, a JIRA issue was just filed to request that we produce a FlexJS
release that has no Adobe dependencies.  I think we can actually do that
now.  Volunteers are needed to make this happen.

Technically, a Cordova app should result in a smaller download than an app
that bundles the entire AIR runtime.  That was important to folks at one
point.  Don't know if it still is.  And a Cordova app can theoretically
run in more places than AIR:  Windows Phone was asked about often at one
point.  Not sure if it is important anymore.

Finally, Adobe (and I think MS, IBM, and other big names) seem to be
continuing to push Cordova.  Aligning FlexJS as the faster way to learn
and use Cordova could bring us much needed resources, attention and
credibility in the enterprise.  I will admit I never shopped for an
alternative to Cordova since Cordova being at Apache made it a no-brainer
for me, but if there are alternatives, we can certainly work with them as
well.

Of course, I could be wrong...
-Alex

Re: [FlexJS] Some things still missing ni FlexJS

[Carlos Rovira]

Hi Vicent,

2017-01-14 13:00 GMT+01:00 Vincent :

> Hi,
>
> Regarding performance using standard display list, it is already possible
> with Flex to develop mobile applications indistinguishable from native ones.
> My understanding of FlexJS is that the framework is much lighter than flex
> so the generated swf should logically perform even better.
>
>
that's what Alex said, so maybe we don't need to go Stage3D. That's great
but I could test that since I was centered on HML rendering


> So what would be the interest of choosing technologies like Cordova
> instead of AIR to generate cross platform mobile apps ?


Hope others could respond to this


>
>
> Vincent.
>
>
>
> Le 13/01/2017 à 19:35, Carlos Rovira a écrit :
>
>> Hi Peter,
>>
>> 2017-01-13 19:22 GMT+01:00 Peter Ent :
>>
>> I was speaking to a friend that has some JavaScript developers working for
>>> him. They use React and React/Native for their mobile apps. His feeling
>>> is
>>> that web-centric apps (e.g. Amazon.com) are going to be replaced with
>>> mobile apps since mobile devices are cheaper than laptops. They are
>>> concentrating their app development to server-side services with native
>>> apps delivered via React/Native.
>>>
>>> IMO then, what FlexJS needs is the ability to go native. This isn't
>>> necessary for a 1.0 launch, but having FlexJS/Native with applications
>>> constructed in ActionScript and MXML and then cross-compiled into Swift
>>> or
>>> Java could go a long way to make FlexJS the platform for cross-device
>>> development.
>>>
>>>
>> I already see that. but for 2.0, as you said native (swift or java) seems
>> huge work.
>> But...what about SWF *native* ?
>> I mean, SWF Stage3D mode is very performant (I think even native) right?
>> I think FeathersUI is Stage3D powered and is performant on Native. someone
>> correct me If I'm wrong.
>> So maybe SWF should be not display object ready but stage3d ready to allow
>> us to have the same performance as native
>>
>> That's is for me the main reason for SWF existence. Alex said that actual
>> SWF FlexJS framework based on display list could be very performant...I
>> don't know since we didn't make any benchmark here and that it had the
>> advantage of have accessibility implemented...
>>
>>
>


-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS] Some things still missing ni FlexJS

[Vincent]

Hi,

Regarding performance using standard display list, it is already 
possible with Flex to develop mobile applications indistinguishable from 
native ones.
My understanding of FlexJS is that the framework is much lighter than 
flex so the generated swf should logically perform even better.


So what would be the interest of choosing technologies like Cordova 
instead of AIR to generate cross platform mobile apps ?


Vincent.


Le 13/01/2017 à 19:35, Carlos Rovira a écrit :

Hi Peter,

2017-01-13 19:22 GMT+01:00 Peter Ent :


I was speaking to a friend that has some JavaScript developers working for
him. They use React and React/Native for their mobile apps. His feeling is
that web-centric apps (e.g. Amazon.com) are going to be replaced with
mobile apps since mobile devices are cheaper than laptops. They are
concentrating their app development to server-side services with native
apps delivered via React/Native.

IMO then, what FlexJS needs is the ability to go native. This isn't
necessary for a 1.0 launch, but having FlexJS/Native with applications
constructed in ActionScript and MXML and then cross-compiled into Swift or
Java could go a long way to make FlexJS the platform for cross-device
development.



I already see that. but for 2.0, as you said native (swift or java) seems
huge work.
But...what about SWF *native* ?
I mean, SWF Stage3D mode is very performant (I think even native) right?
I think FeathersUI is Stage3D powered and is performant on Native. someone
correct me If I'm wrong.
So maybe SWF should be not display object ready but stage3d ready to allow
us to have the same performance as native

That's is for me the main reason for SWF existence. Alex said that actual
SWF FlexJS framework based on display list could be very performant...I
don't know since we didn't make any benchmark here and that it had the
advantage of have accessibility implemented...

Re: [FlexJS] Some things still missing ni FlexJS

[Alex Harui]

On 1/13/17, 11:13 AM, "piotrz"  wrote:

>I was working on Big Flex app where we were using SOAP/XML. - I think now
>we
>can consume XML in FlexJS.

Yes.  You can migrate today if you are using XML, only need to support one
language and don't use modules.  Regarding skinning, in theory your
company already has CSS for branding other web-pages and hopefully a lot
of that can be used in FlexJS assuming the only skinning you need is to
brand the app as opposed to offering lots of different skins for your
customers to choose.

We don't have support for WSDL handling or decoding SOAP to ValueObjects
yet, but instead of us having to write that code before we get more
customers, I keep hoping that one customer will show up and say "I can't
wait to migrate anymore and I think it will be cheaper to have one of my
developers help build out this missing feature than to have my team port
the whole app to some other JS framework."  What I think we need is
"credibility" via a testimonial.  I think folks who have to migrate now
just pass up FlexJS for React or Angular because they aren't sure that
FlexJS is ready.  FlexJS isn't a "safe" choice yet.  That's why if one
person can attest that it was safe enough for them, that could cause one
more person to not pass on us and get the ball rolling faster.


>
>Another thing which came up to my mind - Did we ever write any WIKI page
>to
>show people what actually option of data consuming we have ?
>
>I think if it will be pointed on WIKI and in Release notes somewhere it
>gets
>an attention - What do you think ?

It should be documented somewhere, but that opens the whole debate about
where to document.  Some folks don't want to add more stuff to the wiki.
IMO, as Peter gets going on Tour De FlexJS, that where we should document
the ways to get data.

My 2 cents,
-Alex

Re: [FlexJS] Some things still missing ni FlexJS

[piotrz]

I was working on Big Flex app where we were using SOAP/XML. - I think now we
can consume XML in FlexJS.

Another thing which came up to my mind - Did we ever write any WIKI page to
show people what actually option of data consuming we have ? 

I think if it will be pointed on WIKI and in Release notes somewhere it gets
an attention - What do you think ?

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Some-things-still-missing-ni-FlexJS-tp57985p58257.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Some things still missing ni FlexJS

[Alex Harui]

On 1/13/17, 10:28 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>2017-01-13 19:11 GMT+01:00 Alex Harui :
>
>>
>>
>> IMO, there are at least some existing Flex apps that don't use AMF.  Now
>> it may turn out that we will have AMF shortly, but until it is done,
>>those
>> who don't need it can start migrating their apps today.  Some folks are
>> already migrating.
>
>
>I don't think so. For me flow data comes first and then other things.
>Without server connection I think almost no people will start migrating.
>People even can start a wireframe ugly project, but seeing data is coming
>and they can sent data. Then will come themes, and other eye candy
>things...

Some Flex apps I've seen used SOAP/XML.  I definitely know there is at
least one app under migration now and AIUI, it is using XML not AMF.  I
completely understand that with AMF we will become more attractive to more
Flex customers, but if we can make migration possible for folks using XML
or even JSON, why can't we call that our 1.0?  What would be wrong with
calling that 1.0?

-Alex

Re: [FlexJS] Some things still missing ni FlexJS

[Carlos Rovira]

2017-01-13 19:46 GMT+01:00 Peter Ent :

>
>
> I wasn't thinking of FlexJS/Native as desire to dump SWF and JS-xcompile,
> but FlexJS/Native as a new addition and option for folks who want to work
> in ActionScript and layout their apps in MXML but want a native
> application as the end result, rather than going through Cordova.
>
>
Right! I understand. I want to said that I see as you the benefits to go
native and Swift for iOS and Java for Android. But my point was that
the effort is huge and we could get easily to a v2.0 and one? two years?

I was saying that SWF Stage 3D could give as the performant benefits of
native and could be much easier and doable in less time..but without change
one thing for the other, I still would want iOS and Android Native! :)

Think that others like haxe finaly take the same path, and we should do the
same in the end


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: [FlexJS] Some things still missing ni FlexJS

[Peter Ent]

See in-line.
‹peter

On 1/13/17, 1:35 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Peter,
>
>2017-01-13 19:22 GMT+01:00 Peter Ent :
>
>> I was speaking to a friend that has some JavaScript developers working
>>for
>> him. They use React and React/Native for their mobile apps. His feeling
>>is
>> that web-centric apps (e.g. Amazon.com) are going to be replaced with
>> mobile apps since mobile devices are cheaper than laptops. They are
>> concentrating their app development to server-side services with native
>> apps delivered via React/Native.
>>
>> IMO then, what FlexJS needs is the ability to go native. This isn't
>> necessary for a 1.0 launch, but having FlexJS/Native with applications
>> constructed in ActionScript and MXML and then cross-compiled into Swift
>>or
>> Java could go a long way to make FlexJS the platform for cross-device
>> development.
>>
>
>
>I already see that. but for 2.0, as you said native (swift or java) seems
>huge work.
>But...what about SWF *native* ?
>I mean, SWF Stage3D mode is very performant (I think even native) right?
>I think FeathersUI is Stage3D powered and is performant on Native. someone
>correct me If I'm wrong.
>So maybe SWF should be not display object ready but stage3d ready to allow
>us to have the same performance as native
>
>That's is for me the main reason for SWF existence. Alex said that actual
>SWF FlexJS framework based on display list could be very performant...I
>don't know since we didn't make any benchmark here and that it had the
>advantage of have accessibility implemented...

I wasn't thinking of FlexJS/Native as desire to dump SWF and JS-xcompile,
but FlexJS/Native as a new addition and option for folks who want to work
in ActionScript and layout their apps in MXML but want a native
application as the end result, rather than going through Cordova.

>

Re: [FlexJS] Some things still missing ni FlexJS

[Carlos Rovira]

Hi Peter,

2017-01-13 19:22 GMT+01:00 Peter Ent :

> I was speaking to a friend that has some JavaScript developers working for
> him. They use React and React/Native for their mobile apps. His feeling is
> that web-centric apps (e.g. Amazon.com) are going to be replaced with
> mobile apps since mobile devices are cheaper than laptops. They are
> concentrating their app development to server-side services with native
> apps delivered via React/Native.
>
> IMO then, what FlexJS needs is the ability to go native. This isn't
> necessary for a 1.0 launch, but having FlexJS/Native with applications
> constructed in ActionScript and MXML and then cross-compiled into Swift or
> Java could go a long way to make FlexJS the platform for cross-device
> development.
>


I already see that. but for 2.0, as you said native (swift or java) seems
huge work.
But...what about SWF *native* ?
I mean, SWF Stage3D mode is very performant (I think even native) right?
I think FeathersUI is Stage3D powered and is performant on Native. someone
correct me If I'm wrong.
So maybe SWF should be not display object ready but stage3d ready to allow
us to have the same performance as native

That's is for me the main reason for SWF existence. Alex said that actual
SWF FlexJS framework based on display list could be very performant...I
don't know since we didn't make any benchmark here and that it had the
advantage of have accessibility implemented...

Re: [FlexJS] Some things still missing ni FlexJS

[Carlos Rovira]

2017-01-13 19:11 GMT+01:00 Alex Harui :

>
>
> IMO, there are at least some existing Flex apps that don't use AMF.  Now
> it may turn out that we will have AMF shortly, but until it is done, those
> who don't need it can start migrating their apps today.  Some folks are
> already migrating.


I don't think so. For me flow data comes first and then other things.
Without server connection I think almost no people will start migrating.
People even can start a wireframe ugly project, but seeing data is coming
and they can sent data. Then will come themes, and other eye candy things...



> I will believe that AMF is used by the vast majority
> of Flex apps, but as I said upthread, we simply need to attract more
> committers/contributors to really get FlexJS off the ground.  Some folks
> believe that declaring something as 1.0 will invite more folks to try it
> and thus get involved.


I don't think so. React and others are in 0.15?...and they attract all devs.
If we put some groundbreaking examples and say "hey! this is Flex and we
have a cool component set, modules, AMF..."
People will start then to think in us seriously. Until then we don't have
to much to captivate people coming...



> I don't have a strong opinion, but that sounds
> like a reasonable approach, and better than telling folks not to try
> FlexJS for another year or two and wait for the few of us who are active
> committers to reproduce all of these killer features that a much larger
> team of full-timers did at Adobe over many more years.
>

I think that people will start to join as they can work with flexJS. we
need a set of capabilities that make people could use us in their Apps
We are near, but not still there. and the people that we can't attract more
are the people that has old flex apps as Chris said.


>
> Flex 4 had many more features than Flex 3, which had more features than
> Flex 2 which had more features than Flex 1.0.  FlexJS 1.0 may only allow a
> small percentage of Flex customers to migrate, but again, if that brings
> in new contributors we can handle more Flex customers with FlexJS 2.0 and
> so on.
>

Flex was popular in 2005 when Adobe bought Macromedia and invest money to
make Flex 2.0. That was for me the vortex that make people change from
crappy html/js to Flex/swf


>
> There may also be a way to get traction with new customers and new apps as
> well by trying to get attention from Cordova developers, CreateJS
> developers, etc.


All people I hear talking about Cordoba says "it's crap" and CreateJS is
not very popular...I think we should not see in that direction since is not
the excellence we can reach to be "the top" tech out there.


> I don't care who gets to production first, whether it is
> a new app or migrated app, but mainly, I think a testimonial is what we
> really need since we don't have a budget for marketing.  So when folks
> show up with a need in order to get to production, I will try to help them
> out.
>

For me get the 1.0 state is not related to see a guy or a team that say us
"hey! I made a FlexJS app and I have in pro"...mmm...definitely no.
I see that we are not 1.0...we all see that. We see that we are getting
great advances to that path, but for 1.0 means "the minimum set of things
that allows me to make a FlexJS app" and that means crafting an interface
with controls and layouts (buttons, text inputs, lists, ...), break into
parts (modules) and communicate with server (AMF). That marks a round
circle come from the user browser and go to the server and come back with
something to the user again... and all of that with great "flex"
productivity :)



>
> -Alex
>
>


-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS] Some things still missing ni FlexJS

[Peter Ent]

I was speaking to a friend that has some JavaScript developers working for
him. They use React and React/Native for their mobile apps. His feeling is
that web-centric apps (e.g. Amazon.com) are going to be replaced with
mobile apps since mobile devices are cheaper than laptops. They are
concentrating their app development to server-side services with native
apps delivered via React/Native.

IMO then, what FlexJS needs is the ability to go native. This isn't
necessary for a 1.0 launch, but having FlexJS/Native with applications
constructed in ActionScript and MXML and then cross-compiled into Swift or
Java could go a long way to make FlexJS the platform for cross-device
development.

‹peter

On 1/13/17, 8:58 AM, "Harbs"  wrote:

>I agree with Chris that target #1 is developers migrating from Flash.
>
>But, #2 is a very close second with JS developers looking for better
>productivity.
>
>#2 is where we can have a real win in terms of adoption. I think the
>reason js developers seem to always flutter from framework to framework
>is that they¹re looking for better efficiency and not really finding it.
>
>I¹m not sure what the minimal feature set for version 1 is, but I¹m not
>sure what percentage of enterprise apps use AMF modules and resource
>bundles. It would be interesting to know if there¹s any indicators on
>that.
>
>On Jan 13, 2017, at 10:44 AM, Christofer Dutz 
>wrote:
>
>> Well from my point of view it was the whole ³write once run everywhere²
>>thing. 
>> I was totally annoyed of having to write UI things once and then patch
>>and bugfix things for all the other Browsers.
>> 
>> But in general I think you (Alex) and I have one great difference in
>>our assumption of who will probably be our generation 1 users.
>> 
>> You assume it¹s mainly the people wanting to create new applications.
>>That¹s why you see 1.0 the way you do it.
>> 
>> I, on the other side, think that our generation 1 users would probably
>>be people migrating legacy Flex applications to FlexJS.
>> 
>> The reason, why I think that way, is that no matter what bank or
>>insurance company I have worked for in the last 4 years. I always
>>encounter Flashplayer maintenance updates. I usually ask why Flash? And
>>always get the answer: ³We still got some legacy applications that need
>>that². A little more investigation usually shows that there are loads of
>>applications still in production internally which are built in Flex.
>>There are plans to migrate to JavaScript, but there just isn¹t enough
>>budget to simply rewrite something with the only benefit in the end
>>being no longer to require the Flashplayer. For me ³Flex² is
>>stigmatized. Even if it¹s not deserved, it¹s still a reality. I doubt
>>that someone wanting to try out the latest cool stuff will tend to go
>>directly towards a stigmatized technology, not if there¹s all the cool
>>React, Angular2, Typescript and similar stuff out there that does ³the
>>same we promise to provide².
>> 
>> If we get FlexJS to a point where it¹s easy to migrate we sort of offer
>>the only option the people stuck in a dead-end with Flash have to
>>migrate to JavaScript at a fraction of the costs. That¹s why I¹m
>>continuing to argue to add the most essential Flex features to FlexJS.
>>It doesn¹t matter if AMF support is slower than JSON or than AMF was on
>>Flash. It just have to be there to ease the migration path. Same with
>>skinning. It¹s been used quite a lot and this I one concept where
>>migrating isn¹t just a matter of replacing some classes. If there is no
>>skinning support all the Components have to be completely rewritten.
>>Eventually we could do without modules, even if I think they are
>>essential, but for me it¹s:
>> 
>> - AMF Support
>> - Skinning
>> - Modules
>> - ResourceBundles and I18N
>> 
>> Which we need in order to ease the migration path.
>> 
>> Chris
>> 
>> 
>> Am 13.01.17, 00:24 schrieb "Alex Harui" :
>> 
>> 
>> 
>>On 1/12/17, 12:46 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>>
>>wrote:
>> 
>>> We need some strategy, and we must think about what others are giving
>>>in
>>> comparison with us.
>>> In LTE I think our solution win, but right now is complicate convince
>>> business to choose us over Angular/React, since is world trending.
>>> 
>>> So I'm with Chris that we need to give things others doesn't have, for
>>>me
>>> maven is one of that things, but is something in the backstage.
>>> We need more things on that make us different. One of those things is
>>>AMF,
>>> and since many Flex apps out there have it is a key point to make them
>>> move
>>> to FlexJS.
>> 
>>I guess I'm wondering why folks chose Flex in the first place.  Was
>>it
>>some cool feature?  If so, what was it?  My assumption has been that
>>the
>>real reason folks chose Flex (or maybe the reason they stayed) was
>>about
>>

Re: [FlexJS] Some things still missing ni FlexJS

[Carlos Rovira]

The last time I saw webgl working was testing Unity 3D webgl.
Unity invest much effort and they got it working, but mainly on desktop,
and without great performance.
In mobile devices, was not supported (that was about 6 month ago), and when
playing on iPhone (for example) was really bad experience.

I think webgl is not here yet...at least for what I see.

If it could be I think Adobe smart people would make it




2017-01-13 16:18 GMT+01:00 Dev LFM :

> Actually it would be more easy, if adobe just convert their flashplayer to
> render on webgl and that would work for all...
>
> 2017-01-13 15:15 GMT+00:00 Dev LFM :
>
> > Hi all,
> >
> > For me, as I since 8 years constantly developed content editors for
> > printing labs (basically I would use a Canvas on FlexJS), it was the no
> > crossbrowsing differences, one player that behaves the same on all
> targets
> > (This is the key). My company currently relies on Flash to sell.. and
> > html/js fails on this hard... so in the end I will probably deploy a Air
> > release..
> >
> > Then it was the IDE with good tools for productivity and debug. It is a
> > waste of time patching to solve some IE/Firefox/Chrome issue..
> >
> > Thats why, and listen to this pls, the most valuable thing that FlexJS
> can
> > sell, is the Stage3D/WebGL targets as replacement to flashplayer. Then
> with
> > Cordova for mobile, and Electron for desktop, we would target everywhere
> > and win marketshare like in flex/flash did.
> >
> > We should get that flexjsstage3d from http://matrix3d.github.io/assets/
> > html5/flexjsstage3d/bin/js-release/ and help him finish all
> compatibility
> > with flash stage3d, then port the starling/feathers and we would be on
> top
> > again.
> >
> > AMF and ResourcesBundles / I18N are a must, modules could wait..
> >
> > This is my vision for the future.
> >
> >
> > 2017-01-13 13:58 GMT+00:00 Harbs :
> >
> >> I agree with Chris that target #1 is developers migrating from Flash.
> >>
> >> But, #2 is a very close second with JS developers looking for better
> >> productivity.
> >>
> >> #2 is where we can have a real win in terms of adoption. I think the
> >> reason js developers seem to always flutter from framework to framework
> is
> >> that they’re looking for better efficiency and not really finding it.
> >>
> >> I’m not sure what the minimal feature set for version 1 is, but I’m not
> >> sure what percentage of enterprise apps use AMF modules and resource
> >> bundles. It would be interesting to know if there’s any indicators on
> that.
> >>
> >> On Jan 13, 2017, at 10:44 AM, Christofer Dutz <
> christofer.d...@c-ware.de>
> >> wrote:
> >>
> >> > Well from my point of view it was the whole “write once run
> everywhere”
> >> thing.
> >> > I was totally annoyed of having to write UI things once and then patch
> >> and bugfix things for all the other Browsers.
> >> >
> >> > But in general I think you (Alex) and I have one great difference in
> >> our assumption of who will probably be our generation 1 users.
> >> >
> >> > You assume it’s mainly the people wanting to create new applications.
> >> That’s why you see 1.0 the way you do it.
> >> >
> >> > I, on the other side, think that our generation 1 users would probably
> >> be people migrating legacy Flex applications to FlexJS.
> >> >
> >> > The reason, why I think that way, is that no matter what bank or
> >> insurance company I have worked for in the last 4 years. I always
> encounter
> >> Flashplayer maintenance updates. I usually ask why Flash? And always get
> >> the answer: “We still got some legacy applications that need that”. A
> >> little more investigation usually shows that there are loads of
> >> applications still in production internally which are built in Flex.
> There
> >> are plans to migrate to JavaScript, but there just isn’t enough budget
> to
> >> simply rewrite something with the only benefit in the end being no
> longer
> >> to require the Flashplayer. For me “Flex” is stigmatized. Even if it’s
> not
> >> deserved, it’s still a reality. I doubt that someone wanting to try out
> the
> >> latest cool stuff will tend to go directly towards a stigmatized
> >> technology, not if there’s all the cool React, Angular2, Typescript and
> >> similar stuff out there that does “the same we promise to provide”.
> >> >
> >> > If we get FlexJS to a point where it’s easy to migrate we sort of
> offer
> >> the only option the people stuck in a dead-end with Flash have to
> migrate
> >> to JavaScript at a fraction of the costs. That’s why I’m continuing to
> >> argue to add the most essential Flex features to FlexJS. It doesn’t
> matter
> >> if AMF support is slower than JSON or than AMF was on Flash. It just
> have
> >> to be there to ease the migration path. Same with skinning. It’s been
> used
> >> quite a lot and this I one concept where migrating isn’t just a matter
> of
> >> replacing some classes. If there is no 

Re: [FlexJS] Some things still missing ni FlexJS

[Alex Harui]

On 1/13/17, 12:44 AM, "Christofer Dutz"  wrote:

>Well from my point of view it was the whole “write once run everywhere”
>thing. 
>I was totally annoyed of having to write UI things once and then patch
>and bugfix things for all the other Browsers.

I would say that fits under the "Developer Productivity" umbrella.

>
>But in general I think you (Alex) and I have one great difference in our
>assumption of who will probably be our generation 1 users.
>
>You assume it’s mainly the people wanting to create new applications.
>That’s why you see 1.0 the way you do it.

That is an incorrect assumption.

IMO, there are at least some existing Flex apps that don't use AMF.  Now
it may turn out that we will have AMF shortly, but until it is done, those
who don't need it can start migrating their apps today.  Some folks are
already migrating.  I will believe that AMF is used by the vast majority
of Flex apps, but as I said upthread, we simply need to attract more
committers/contributors to really get FlexJS off the ground.  Some folks
believe that declaring something as 1.0 will invite more folks to try it
and thus get involved.  I don't have a strong opinion, but that sounds
like a reasonable approach, and better than telling folks not to try
FlexJS for another year or two and wait for the few of us who are active
committers to reproduce all of these killer features that a much larger
team of full-timers did at Adobe over many more years.

Flex 4 had many more features than Flex 3, which had more features than
Flex 2 which had more features than Flex 1.0.  FlexJS 1.0 may only allow a
small percentage of Flex customers to migrate, but again, if that brings
in new contributors we can handle more Flex customers with FlexJS 2.0 and
so on.

There may also be a way to get traction with new customers and new apps as
well by trying to get attention from Cordova developers, CreateJS
developers, etc.  I don't care who gets to production first, whether it is
a new app or migrated app, but mainly, I think a testimonial is what we
really need since we don't have a budget for marketing.  So when folks
show up with a need in order to get to production, I will try to help them
out.

-Alex

Re: [FlexJS] Some things still missing ni FlexJS

[Dev LFM]

Actually it would be more easy, if adobe just convert their flashplayer to
render on webgl and that would work for all...

2017-01-13 15:15 GMT+00:00 Dev LFM :

> Hi all,
>
> For me, as I since 8 years constantly developed content editors for
> printing labs (basically I would use a Canvas on FlexJS), it was the no
> crossbrowsing differences, one player that behaves the same on all targets
> (This is the key). My company currently relies on Flash to sell.. and
> html/js fails on this hard... so in the end I will probably deploy a Air
> release..
>
> Then it was the IDE with good tools for productivity and debug. It is a
> waste of time patching to solve some IE/Firefox/Chrome issue..
>
> Thats why, and listen to this pls, the most valuable thing that FlexJS can
> sell, is the Stage3D/WebGL targets as replacement to flashplayer. Then with
> Cordova for mobile, and Electron for desktop, we would target everywhere
> and win marketshare like in flex/flash did.
>
> We should get that flexjsstage3d from http://matrix3d.github.io/assets/
> html5/flexjsstage3d/bin/js-release/ and help him finish all compatibility
> with flash stage3d, then port the starling/feathers and we would be on top
> again.
>
> AMF and ResourcesBundles / I18N are a must, modules could wait..
>
> This is my vision for the future.
>
>
> 2017-01-13 13:58 GMT+00:00 Harbs :
>
>> I agree with Chris that target #1 is developers migrating from Flash.
>>
>> But, #2 is a very close second with JS developers looking for better
>> productivity.
>>
>> #2 is where we can have a real win in terms of adoption. I think the
>> reason js developers seem to always flutter from framework to framework is
>> that they’re looking for better efficiency and not really finding it.
>>
>> I’m not sure what the minimal feature set for version 1 is, but I’m not
>> sure what percentage of enterprise apps use AMF modules and resource
>> bundles. It would be interesting to know if there’s any indicators on that.
>>
>> On Jan 13, 2017, at 10:44 AM, Christofer Dutz 
>> wrote:
>>
>> > Well from my point of view it was the whole “write once run everywhere”
>> thing.
>> > I was totally annoyed of having to write UI things once and then patch
>> and bugfix things for all the other Browsers.
>> >
>> > But in general I think you (Alex) and I have one great difference in
>> our assumption of who will probably be our generation 1 users.
>> >
>> > You assume it’s mainly the people wanting to create new applications.
>> That’s why you see 1.0 the way you do it.
>> >
>> > I, on the other side, think that our generation 1 users would probably
>> be people migrating legacy Flex applications to FlexJS.
>> >
>> > The reason, why I think that way, is that no matter what bank or
>> insurance company I have worked for in the last 4 years. I always encounter
>> Flashplayer maintenance updates. I usually ask why Flash? And always get
>> the answer: “We still got some legacy applications that need that”. A
>> little more investigation usually shows that there are loads of
>> applications still in production internally which are built in Flex. There
>> are plans to migrate to JavaScript, but there just isn’t enough budget to
>> simply rewrite something with the only benefit in the end being no longer
>> to require the Flashplayer. For me “Flex” is stigmatized. Even if it’s not
>> deserved, it’s still a reality. I doubt that someone wanting to try out the
>> latest cool stuff will tend to go directly towards a stigmatized
>> technology, not if there’s all the cool React, Angular2, Typescript and
>> similar stuff out there that does “the same we promise to provide”.
>> >
>> > If we get FlexJS to a point where it’s easy to migrate we sort of offer
>> the only option the people stuck in a dead-end with Flash have to migrate
>> to JavaScript at a fraction of the costs. That’s why I’m continuing to
>> argue to add the most essential Flex features to FlexJS. It doesn’t matter
>> if AMF support is slower than JSON or than AMF was on Flash. It just have
>> to be there to ease the migration path. Same with skinning. It’s been used
>> quite a lot and this I one concept where migrating isn’t just a matter of
>> replacing some classes. If there is no skinning support all the Components
>> have to be completely rewritten. Eventually we could do without modules,
>> even if I think they are essential, but for me it’s:
>> >
>> > - AMF Support
>> > - Skinning
>> > - Modules
>> > - ResourceBundles and I18N
>> >
>> > Which we need in order to ease the migration path.
>> >
>> > Chris
>> >
>> >
>> > Am 13.01.17, 00:24 schrieb "Alex Harui" :
>> >
>> >
>> >
>> >On 1/12/17, 12:46 AM, "carlos.rov...@gmail.com on behalf of Carlos
>> Rovira"
>> >
>> wrote:
>> >
>> >> We need some strategy, and we must think about what others are giving
>> in
>> >> comparison 

Re: [FlexJS] Some things still missing ni FlexJS

[Harbs]

I agree with Chris that target #1 is developers migrating from Flash.

But, #2 is a very close second with JS developers looking for better 
productivity.

#2 is where we can have a real win in terms of adoption. I think the reason js 
developers seem to always flutter from framework to framework is that they’re 
looking for better efficiency and not really finding it.

I’m not sure what the minimal feature set for version 1 is, but I’m not sure 
what percentage of enterprise apps use AMF modules and resource bundles. It 
would be interesting to know if there’s any indicators on that.

On Jan 13, 2017, at 10:44 AM, Christofer Dutz  wrote:

> Well from my point of view it was the whole “write once run everywhere” 
> thing. 
> I was totally annoyed of having to write UI things once and then patch and 
> bugfix things for all the other Browsers.
> 
> But in general I think you (Alex) and I have one great difference in our 
> assumption of who will probably be our generation 1 users.
> 
> You assume it’s mainly the people wanting to create new applications. That’s 
> why you see 1.0 the way you do it. 
> 
> I, on the other side, think that our generation 1 users would probably be 
> people migrating legacy Flex applications to FlexJS.
> 
> The reason, why I think that way, is that no matter what bank or insurance 
> company I have worked for in the last 4 years. I always encounter Flashplayer 
> maintenance updates. I usually ask why Flash? And always get the answer: “We 
> still got some legacy applications that need that”. A little more 
> investigation usually shows that there are loads of applications still in 
> production internally which are built in Flex. There are plans to migrate to 
> JavaScript, but there just isn’t enough budget to simply rewrite something 
> with the only benefit in the end being no longer to require the Flashplayer. 
> For me “Flex” is stigmatized. Even if it’s not deserved, it’s still a 
> reality. I doubt that someone wanting to try out the latest cool stuff will 
> tend to go directly towards a stigmatized technology, not if there’s all the 
> cool React, Angular2, Typescript and similar stuff out there that does “the 
> same we promise to provide”. 
> 
> If we get FlexJS to a point where it’s easy to migrate we sort of offer the 
> only option the people stuck in a dead-end with Flash have to migrate to 
> JavaScript at a fraction of the costs. That’s why I’m continuing to argue to 
> add the most essential Flex features to FlexJS. It doesn’t matter if AMF 
> support is slower than JSON or than AMF was on Flash. It just have to be 
> there to ease the migration path. Same with skinning. It’s been used quite a 
> lot and this I one concept where migrating isn’t just a matter of replacing 
> some classes. If there is no skinning support all the Components have to be 
> completely rewritten. Eventually we could do without modules, even if I think 
> they are essential, but for me it’s:
> 
> - AMF Support
> - Skinning
> - Modules
> - ResourceBundles and I18N
> 
> Which we need in order to ease the migration path.
> 
> Chris
> 
> 
> Am 13.01.17, 00:24 schrieb "Alex Harui" :
> 
> 
> 
>On 1/12/17, 12:46 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
> wrote:
> 
>> We need some strategy, and we must think about what others are giving in
>> comparison with us.
>> In LTE I think our solution win, but right now is complicate convince
>> business to choose us over Angular/React, since is world trending.
>> 
>> So I'm with Chris that we need to give things others doesn't have, for me
>> maven is one of that things, but is something in the backstage.
>> We need more things on that make us different. One of those things is AMF,
>> and since many Flex apps out there have it is a key point to make them
>> move
>> to FlexJS.
> 
>I guess I'm wondering why folks chose Flex in the first place.  Was it
>some cool feature?  If so, what was it?  My assumption has been that the
>real reason folks chose Flex (or maybe the reason they stayed) was about
>Developer Productivity.  A feature fight will be very difficult for us to
>win without more contributors.  Any feature we can produce as an advantage
>would likely be short-lived:  the other frameworks will simply produce the
>same feature.
> 
>But we can win or at least compare more favorably on helping you get your
>app into production faster and having fewer maintenance issues because we
>are a single-source provider of both a declarative language and an
>object-oriented language and have a tool chain in our workflow.  And, I
>still believe that having a SWF version of your app will be very valuable.
> For those who are interested in modules, without the runtime verification
>that Flash has, you will be at the mercy of any synchronization issues
>between the 

Re: [FlexJS] Some things still missing ni FlexJS

[Christofer Dutz]

Well from my point of view it was the whole “write once run everywhere” thing. 
I was totally annoyed of having to write UI things once and then patch and 
bugfix things for all the other Browsers.

But in general I think you (Alex) and I have one great difference in our 
assumption of who will probably be our generation 1 users.

You assume it’s mainly the people wanting to create new applications. That’s 
why you see 1.0 the way you do it. 

I, on the other side, think that our generation 1 users would probably be 
people migrating legacy Flex applications to FlexJS.

The reason, why I think that way, is that no matter what bank or insurance 
company I have worked for in the last 4 years. I always encounter Flashplayer 
maintenance updates. I usually ask why Flash? And always get the answer: “We 
still got some legacy applications that need that”. A little more investigation 
usually shows that there are loads of applications still in production 
internally which are built in Flex. There are plans to migrate to JavaScript, 
but there just isn’t enough budget to simply rewrite something with the only 
benefit in the end being no longer to require the Flashplayer. For me “Flex” is 
stigmatized. Even if it’s not deserved, it’s still a reality. I doubt that 
someone wanting to try out the latest cool stuff will tend to go directly 
towards a stigmatized technology, not if there’s all the cool React, Angular2, 
Typescript and similar stuff out there that does “the same we promise to 
provide”. 

If we get FlexJS to a point where it’s easy to migrate we sort of offer the 
only option the people stuck in a dead-end with Flash have to migrate to 
JavaScript at a fraction of the costs. That’s why I’m continuing to argue to 
add the most essential Flex features to FlexJS. It doesn’t matter if AMF 
support is slower than JSON or than AMF was on Flash. It just have to be there 
to ease the migration path. Same with skinning. It’s been used quite a lot and 
this I one concept where migrating isn’t just a matter of replacing some 
classes. If there is no skinning support all the Components have to be 
completely rewritten. Eventually we could do without modules, even if I think 
they are essential, but for me it’s:

- AMF Support
- Skinning
- Modules
- ResourceBundles and I18N

Which we need in order to ease the migration path.

Chris


Am 13.01.17, 00:24 schrieb "Alex Harui" :



On 1/12/17, 12:46 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>We need some strategy, and we must think about what others are giving in
>comparison with us.
>In LTE I think our solution win, but right now is complicate convince
>business to choose us over Angular/React, since is world trending.
>
>So I'm with Chris that we need to give things others doesn't have, for me
>maven is one of that things, but is something in the backstage.
>We need more things on that make us different. One of those things is AMF,
>and since many Flex apps out there have it is a key point to make them
>move
>to FlexJS.

I guess I'm wondering why folks chose Flex in the first place.  Was it
some cool feature?  If so, what was it?  My assumption has been that the
real reason folks chose Flex (or maybe the reason they stayed) was about
Developer Productivity.  A feature fight will be very difficult for us to
win without more contributors.  Any feature we can produce as an advantage
would likely be short-lived:  the other frameworks will simply produce the
same feature.

But we can win or at least compare more favorably on helping you get your
app into production faster and having fewer maintenance issues because we
are a single-source provider of both a declarative language and an
object-oriented language and have a tool chain in our workflow.  And, I
still believe that having a SWF version of your app will be very valuable.
 For those who are interested in modules, without the runtime verification
that Flash has, you will be at the mercy of any synchronization issues
between the code that loads the module and the code in the module.  Flash
will tell you right when the module loads that it doesn't meet the
interface contract.  When will you find out when running just in JS?

My 2 cents,
-Alex

Re: [FlexJS] Some things still missing ni FlexJS

[Carlos Rovira]

We need some strategy, and we must think about what others are giving in
comparison with us.
In LTE I think our solution win, but right now is complicate convince
business to choose us over Angular/React, since is world trending.

So I'm with Chris that we need to give things others doesn't have, for me
maven is one of that things, but is something in the backstage.
We need more things on that make us different. One of those things is AMF,
and since many Flex apps out there have it is a key point to make them move
to FlexJS.

It's a matter of what I need to wait to get the rest of features. I can
start writing an App in FlexJS, but I need to put on place the way I
communicate with server from day Zero.
As well I need to break into modules to prepare the places. Then I can wait
for localization, routing, and others to update my App. That's at least the
way I see it, very personal approach, but I think valid for many of us here.



2017-01-12 9:24 GMT+01:00 yishayw <yishayj...@hotmail.com>:

> OmPrakash Muppirala wrote
> > If folks feel comfortable with the ease of use, extensibility and
> > stability
> > of FlexJS, they will start showing interest.  At that point, any missing
> > killer features can be talked about.  Enterprise companies can join us in
> > the effort to add any features they think are terribly important for
> them.
>
> I concur. I think our focus should be on making the current feature set
> production quality, including bug fixes and good documentation. We want the
> average developer to feel comfortable that s/he can use this and get things
> done with it.
>
>
>
>
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/FlexJS-Some-things-still-
> missing-ni-FlexJS-tp57985p58192.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>



-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS] Some things still missing ni FlexJS

[yishayw]

OmPrakash Muppirala wrote
> If folks feel comfortable with the ease of use, extensibility and
> stability
> of FlexJS, they will start showing interest.  At that point, any missing
> killer features can be talked about.  Enterprise companies can join us in
> the effort to add any features they think are terribly important for them.

I concur. I think our focus should be on making the current feature set
production quality, including bug fixes and good documentation. We want the
average developer to feel comfortable that s/he can use this and get things
done with it.




--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Some-things-still-missing-ni-FlexJS-tp57985p58192.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Some things still missing ni FlexJS

[Carlos Rovira]

Hi Peter,

is possible to expose the AMF services in JSON. For example, people in Java
are using Jersey (https://jersey.java.net), but that's not the point. We
can always do as many changes as we want...but we need to say to people "we
have FlexJS with AMF support and you can migrate from Flex to FlexJS only
changing the client part and without touching any line of code in you
server side code or deployment"

2017-01-11 20:41 GMT+01:00 Peter Ent :

> Thanks. I was just wondering if you had services that used both AMF and
> REST/JSON so that those Flex projects migrated to FlexJS could just use
> JSON instead.
>
> ‹peter
>
> On 1/11/17, 2:06 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
> 
> wrote:
>
> >Hi Peter,
> >
> >There are new projects using React with Rest and Json. Think that was
> >started from scratch. I'm referring to migrate old systems that still are
> >stuck in Flex SDK and we have the opportunity to change to FlexJS. Those
> >projects was done with AMF (and as I said many others out there).
> >
> >If we lose the opportunity to propose FlexJS for that migrations
> >(projects)
> >we are loosing a great portfolio of projects that could trust in FlexJS as
> >its next technology.
> >
> >
> >
> >2017-01-11 14:22 GMT+01:00 Peter Ent :
> >
> >>
> >> Are people in your company already using React and if they are, what do
> >> they use to communicate with your backend systems? REST with JSON
> >>results?
> >>
> >>
> >--
> >
> >Carlos Rovira
> >Director General
> >M: +34 607 22 60 05
> >http://www.codeoscopic.com
> >http://www.avant2.es
> >
> >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.
>
>


-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS] Some things still missing ni FlexJS

[Carlos Rovira]

Completely agree. FlexJS should get some prestige in order to be a
technology of choice in front of others people bettings like React or
Angular. We are fighting against all the world that put React and Angular
where they are now. And is a very difficult fight since they has Google and
Facebook behind, while Bootstrap has Twitter and MDL has Google (again)...

Maybe we even don't get to be the main option in the mainstream, but I
think we don't need that while we create a quality product that will be
appreciated by people using it. For example, haxe technology is great, but
it never get the adoption of other technologies, but they has their own
user base and,don't know numbers, but I'm sure they has a good user base...



2017-01-11 19:53 GMT+01:00 OmPrakash Muppirala <bigosma...@gmail.com>:

> The way I see it, folks who are using Javascript frameworks or Flex SDK
> today are going to first test the waters with FlexJS to see if it supports
> basic things.  They will quickly build some prototypes to share with their
> team or leads.  No one is going to move production code right away to
> FlexJS.
>
> If folks feel comfortable with the ease of use, extensibility and stability
> of FlexJS, they will start showing interest.  At that point, any missing
> killer features can be talked about.  Enterprise companies can join us in
> the effort to add any features they think are terribly important for them.
>
> We as a group of volunteers cannot anticipate every need and build
> everything up front.  But I am very confident that any such feature
> requests can be quickly built by the community or by contributors from
> commercial companies.
>
> Just my 2 cents.
>
> Thanks,
> Om
>
> On Wed, Jan 11, 2017 at 10:40 AM, Christofer Dutz <
> christofer.d...@c-ware.de
> > wrote:
>
> > I would rather have a 1.0 that has some killer features the others don't
> > have. I wouldn't be working that much on something that just wants to
> catch
> > up to be on par with something else. Having distinguishable features is
> > essential, from my point of view, to get people to try something.
> >
> > Chris
> >
> >
> >
> > Von meinem Samsung Galaxy Smartphone gesendet.
> >
> >
> > -------- Ursprüngliche Nachricht ----
> > Von: Alex Harui <aha...@adobe.com>
> > Datum: 11.01.17 17:22 (GMT+01:00)
> > An: dev@flex.apache.org
> > Betreff: Re: [FlexJS] Some things still missing ni FlexJS
> >
> >
> >
> > On 1/11/17, 1:43 AM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira"
> > <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com>
> > wrote:
> >
> > >Hi Alex,
> > >
> > >I think many people in this thread are saying "No, we'll not go to
> > >production without AMF and basic module support". IMHO, it would be very
> > >difficult to say we have 1.0 without that, since AMF/RemoteObject was in
> > >almost 99% of old Flex SDK, with some HTTPServices and almost no
> > >WebServices (I mean the MXML object).
> >
> > Is it really 99%?  IMO, the question is whether calling some near-future
> > release 1.0 would help bring in more customers and thus more
> contributors.
> >  There is no doubt that modules and AMF will attract more people, but the
> > longer people sit on the sidelines waiting for the half-dozen or so folks
> > who have committed code in the past year to reproduce what a much larger
> > team produced over 9 years, the less potential customers we will have
> > because some will be forced to move sooner than we can get all of this
> > stuff done.
> >
> > And when those folks are forced to move, they will have to move off of
> AMF
> > anyway.  And if AMF turns out not to be performant enough, the other
> > customers who did wait will have to move off of AMF anyway.
> >
> > So, it is a judgement call, and I don't really care too much which
> release
> > we call 1.0.  My personal opinion is that when somebody who doesn't need
> > AMF and modules goes to production, that is good enough, because then
> > another small set of customers might say "ok, that's good enough for me
> > too" and some of them will become committers.  We just need to attract
> > more committers and waiting for a smaller team to produce more features
> > may not be the right strategy.  Some folks think that the label "1.0"
> will
> > bring new customers.   I'm not sure how important that is because I see
> > lots of other JS frameworks at versions < 0, but I don't have to sell
> > folks on Flex so I don't know.
> >
> &g

Re: [FlexJS] Some things still missing ni FlexJS

[Peter Ent]

Thanks. I was just wondering if you had services that used both AMF and
REST/JSON so that those Flex projects migrated to FlexJS could just use
JSON instead.

‹peter

On 1/11/17, 2:06 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Peter,
>
>There are new projects using React with Rest and Json. Think that was
>started from scratch. I'm referring to migrate old systems that still are
>stuck in Flex SDK and we have the opportunity to change to FlexJS. Those
>projects was done with AMF (and as I said many others out there).
>
>If we lose the opportunity to propose FlexJS for that migrations
>(projects)
>we are loosing a great portfolio of projects that could trust in FlexJS as
>its next technology.
>
>
>
>2017-01-11 14:22 GMT+01:00 Peter Ent :
>
>>
>> Are people in your company already using React and if they are, what do
>> they use to communicate with your backend systems? REST with JSON
>>results?
>>
>>
>-- 
>
>Carlos Rovira
>Director General
>M: +34 607 22 60 05
>http://www.codeoscopic.com
>http://www.avant2.es
>
>Este mensaje se dirige exclusivamente a su destinatario y puede contener
>información privilegiada o confidencial. Si ha recibido este mensaje por
>error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
>proceda a su destrucción.
>
>De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>comunicamos
>que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
>S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>servicio o información solicitados, teniendo usted derecho de acceso,
>rectificación, cancelación y oposición de sus datos dirigiéndose a
>nuestras
>oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
>necesaria.

Re: [FlexJS] Some things still missing ni FlexJS

[Carlos Rovira]

Hi Peter,

There are new projects using React with Rest and Json. Think that was
started from scratch. I'm referring to migrate old systems that still are
stuck in Flex SDK and we have the opportunity to change to FlexJS. Those
projects was done with AMF (and as I said many others out there).

If we lose the opportunity to propose FlexJS for that migrations (projects)
we are loosing a great portfolio of projects that could trust in FlexJS as
its next technology.



2017-01-11 14:22 GMT+01:00 Peter Ent :

>
> Are people in your company already using React and if they are, what do
> they use to communicate with your backend systems? REST with JSON results?
>
>
-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS] Some things still missing ni FlexJS

[OmPrakash Muppirala]

The way I see it, folks who are using Javascript frameworks or Flex SDK
today are going to first test the waters with FlexJS to see if it supports
basic things.  They will quickly build some prototypes to share with their
team or leads.  No one is going to move production code right away to
FlexJS.

If folks feel comfortable with the ease of use, extensibility and stability
of FlexJS, they will start showing interest.  At that point, any missing
killer features can be talked about.  Enterprise companies can join us in
the effort to add any features they think are terribly important for them.

We as a group of volunteers cannot anticipate every need and build
everything up front.  But I am very confident that any such feature
requests can be quickly built by the community or by contributors from
commercial companies.

Just my 2 cents.

Thanks,
Om

On Wed, Jan 11, 2017 at 10:40 AM, Christofer Dutz <christofer.d...@c-ware.de
> wrote:

> I would rather have a 1.0 that has some killer features the others don't
> have. I wouldn't be working that much on something that just wants to catch
> up to be on par with something else. Having distinguishable features is
> essential, from my point of view, to get people to try something.
>
> Chris
>
>
>
> Von meinem Samsung Galaxy Smartphone gesendet.
>
>
>  Ursprüngliche Nachricht 
> Von: Alex Harui <aha...@adobe.com>
> Datum: 11.01.17 17:22 (GMT+01:00)
> An: dev@flex.apache.org
> Betreff: Re: [FlexJS] Some things still missing ni FlexJS
>
>
>
> On 1/11/17, 1:43 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
> <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com>
> wrote:
>
> >Hi Alex,
> >
> >I think many people in this thread are saying "No, we'll not go to
> >production without AMF and basic module support". IMHO, it would be very
> >difficult to say we have 1.0 without that, since AMF/RemoteObject was in
> >almost 99% of old Flex SDK, with some HTTPServices and almost no
> >WebServices (I mean the MXML object).
>
> Is it really 99%?  IMO, the question is whether calling some near-future
> release 1.0 would help bring in more customers and thus more contributors.
>  There is no doubt that modules and AMF will attract more people, but the
> longer people sit on the sidelines waiting for the half-dozen or so folks
> who have committed code in the past year to reproduce what a much larger
> team produced over 9 years, the less potential customers we will have
> because some will be forced to move sooner than we can get all of this
> stuff done.
>
> And when those folks are forced to move, they will have to move off of AMF
> anyway.  And if AMF turns out not to be performant enough, the other
> customers who did wait will have to move off of AMF anyway.
>
> So, it is a judgement call, and I don't really care too much which release
> we call 1.0.  My personal opinion is that when somebody who doesn't need
> AMF and modules goes to production, that is good enough, because then
> another small set of customers might say "ok, that's good enough for me
> too" and some of them will become committers.  We just need to attract
> more committers and waiting for a smaller team to produce more features
> may not be the right strategy.  Some folks think that the label "1.0" will
> bring new customers.   I'm not sure how important that is because I see
> lots of other JS frameworks at versions < 0, but I don't have to sell
> folks on Flex so I don't know.
>
> I just remembered that back in November, Prashant was trying to get AMF up
> and running, but I don't know what happened to that effort.  When you
> finish up MDL, maybe you can help out there.
>
> -Alex
>
> >
> >As well, for a basic experiment, people could go without modules, but for
> >a
> >producction App, a basic load of modules is needed.
> >
> >Then, i18n, Routing, Unit and Functionality testing and so on should come,
> >but for me (If I must to choose) that could come after 1.0
> >
> >For example, in my own company, without AMF and Modules I don't have
> >enough
> >to put FlexJS over React to ask people to use it over the other... (and I
> >know that we'll find many other little things we need in the road)
> >
> >Just my 2ctns
> >
> >
> >2017-01-10 18:11 GMT+01:00 Alex Harui <aha...@adobe.com>:
> >
> >> In my mind, there is little doubt that someone will someday implement
> >>AMF
> >> and not-unloadable modules.  The question is when?  IMO, as soon as
> >> someone can tell us they've gone to production with the code we have,
> >>I'm
> >> willing to ca

AW: [FlexJS] Some things still missing ni FlexJS

[Christofer Dutz]

I would rather have a 1.0 that has some killer features the others don't have. 
I wouldn't be working that much on something that just wants to catch up to be 
on par with something else. Having distinguishable features is essential, from 
my point of view, to get people to try something.

Chris



Von meinem Samsung Galaxy Smartphone gesendet.


 Ursprüngliche Nachricht 
Von: Alex Harui <aha...@adobe.com>
Datum: 11.01.17 17:22 (GMT+01:00)
An: dev@flex.apache.org
Betreff: Re: [FlexJS] Some things still missing ni FlexJS



On 1/11/17, 1:43 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> wrote:

>Hi Alex,
>
>I think many people in this thread are saying "No, we'll not go to
>production without AMF and basic module support". IMHO, it would be very
>difficult to say we have 1.0 without that, since AMF/RemoteObject was in
>almost 99% of old Flex SDK, with some HTTPServices and almost no
>WebServices (I mean the MXML object).

Is it really 99%?  IMO, the question is whether calling some near-future
release 1.0 would help bring in more customers and thus more contributors.
 There is no doubt that modules and AMF will attract more people, but the
longer people sit on the sidelines waiting for the half-dozen or so folks
who have committed code in the past year to reproduce what a much larger
team produced over 9 years, the less potential customers we will have
because some will be forced to move sooner than we can get all of this
stuff done.

And when those folks are forced to move, they will have to move off of AMF
anyway.  And if AMF turns out not to be performant enough, the other
customers who did wait will have to move off of AMF anyway.

So, it is a judgement call, and I don't really care too much which release
we call 1.0.  My personal opinion is that when somebody who doesn't need
AMF and modules goes to production, that is good enough, because then
another small set of customers might say "ok, that's good enough for me
too" and some of them will become committers.  We just need to attract
more committers and waiting for a smaller team to produce more features
may not be the right strategy.  Some folks think that the label "1.0" will
bring new customers.   I'm not sure how important that is because I see
lots of other JS frameworks at versions < 0, but I don't have to sell
folks on Flex so I don't know.

I just remembered that back in November, Prashant was trying to get AMF up
and running, but I don't know what happened to that effort.  When you
finish up MDL, maybe you can help out there.

-Alex

>
>As well, for a basic experiment, people could go without modules, but for
>a
>producction App, a basic load of modules is needed.
>
>Then, i18n, Routing, Unit and Functionality testing and so on should come,
>but for me (If I must to choose) that could come after 1.0
>
>For example, in my own company, without AMF and Modules I don't have
>enough
>to put FlexJS over React to ask people to use it over the other... (and I
>know that we'll find many other little things we need in the road)
>
>Just my 2ctns
>
>
>2017-01-10 18:11 GMT+01:00 Alex Harui <aha...@adobe.com>:
>
>> In my mind, there is little doubt that someone will someday implement
>>AMF
>> and not-unloadable modules.  The question is when?  IMO, as soon as
>> someone can tell us they've gone to production with the code we have,
>>I'm
>> willing to call that 1.0, and the people who wrote that app probably
>> migrated a single SWF, single-language, XML or REST app.  Regular Flex
>> grew just fine and it didn’t support modules in 1.0.
>>
>> For sure, as we add modules, AMF, I18N, we'll gain more customers, but I
>> am hesitant to say these are all 1.0 required features.
>>
>> Thoughts?
>> -Alex
>>
>> On 1/10/17, 6:28 AM, "Dev LFM" <developer...@gmail.com> wrote:
>>
>> >+1
>> >
>> >2017-01-10 14:09 GMT+00:00 Fréderic Cox <coxfrede...@gmail.com>:
>> >
>> >> AMF is also essential for us to take FlexJS serious as a replacement
>>to
>> >> Flex
>> >>
>> >> On Tue, Jan 10, 2017 at 2:41 PM, Vincent <vinc...@after24.net> wrote:
>> >>
>> >> > Hello,
>> >> >
>> >> > Same points than Christopher : AMF and modules.
>> >> > The first is essential for us.
>> >> >
>> >> > Vincent.
>> >> >
>> >> >
>> >> >
>> >> > Le 10/01/2017 à 13:07, Christofer Dutz a écrit :
>> >> >
>> >> >> +1 for the AMF and +1 for not-unloadable modules.
>>

Re: [FlexJS] Some things still missing ni FlexJS

[Alex Harui]

Excellent.  Looking forward to it.

On 1/11/17, 8:54 AM, "PKumar"  wrote:

>Alex,
>
>I have ported the following amfjs library in FlexjS and working fine with
>BlazeDS. But due to busy schedule i could  not further continue on class
>mapping part. Currently i am getting the Object from BlazeDS with one
>"_explicitType" field. Now i need to map that Object to correct class.
>Hopefully this week i will do some progress.
>
>https://github.com/emilkm/amfjs
>
>
>
>
>--
>View this message in context:
>http://apache-flex-development.247.n4.nabble.com/FlexJS-Some-things-st
>ill-missing-ni-FlexJS-tp57985p58164.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Some things still missing ni FlexJS

[PKumar]

Alex,

I have ported the following amfjs library in FlexjS and working fine with
BlazeDS. But due to busy schedule i could  not further continue on class
mapping part. Currently i am getting the Object from BlazeDS with one
"_explicitType" field. Now i need to map that Object to correct class.
Hopefully this week i will do some progress.

https://github.com/emilkm/amfjs




--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Some-things-still-missing-ni-FlexJS-tp57985p58164.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Some things still missing ni FlexJS

[Alex Harui]

On 1/11/17, 1:43 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>I think many people in this thread are saying "No, we'll not go to
>production without AMF and basic module support". IMHO, it would be very
>difficult to say we have 1.0 without that, since AMF/RemoteObject was in
>almost 99% of old Flex SDK, with some HTTPServices and almost no
>WebServices (I mean the MXML object).

Is it really 99%?  IMO, the question is whether calling some near-future
release 1.0 would help bring in more customers and thus more contributors.
 There is no doubt that modules and AMF will attract more people, but the
longer people sit on the sidelines waiting for the half-dozen or so folks
who have committed code in the past year to reproduce what a much larger
team produced over 9 years, the less potential customers we will have
because some will be forced to move sooner than we can get all of this
stuff done.

And when those folks are forced to move, they will have to move off of AMF
anyway.  And if AMF turns out not to be performant enough, the other
customers who did wait will have to move off of AMF anyway.

So, it is a judgement call, and I don't really care too much which release
we call 1.0.  My personal opinion is that when somebody who doesn't need
AMF and modules goes to production, that is good enough, because then
another small set of customers might say "ok, that's good enough for me
too" and some of them will become committers.  We just need to attract
more committers and waiting for a smaller team to produce more features
may not be the right strategy.  Some folks think that the label "1.0" will
bring new customers.   I'm not sure how important that is because I see
lots of other JS frameworks at versions < 0, but I don't have to sell
folks on Flex so I don't know.

I just remembered that back in November, Prashant was trying to get AMF up
and running, but I don't know what happened to that effort.  When you
finish up MDL, maybe you can help out there.

-Alex

>
>As well, for a basic experiment, people could go without modules, but for
>a
>producction App, a basic load of modules is needed.
>
>Then, i18n, Routing, Unit and Functionality testing and so on should come,
>but for me (If I must to choose) that could come after 1.0
>
>For example, in my own company, without AMF and Modules I don't have
>enough
>to put FlexJS over React to ask people to use it over the other... (and I
>know that we'll find many other little things we need in the road)
>
>Just my 2ctns
>
>
>2017-01-10 18:11 GMT+01:00 Alex Harui :
>
>> In my mind, there is little doubt that someone will someday implement
>>AMF
>> and not-unloadable modules.  The question is when?  IMO, as soon as
>> someone can tell us they've gone to production with the code we have,
>>I'm
>> willing to call that 1.0, and the people who wrote that app probably
>> migrated a single SWF, single-language, XML or REST app.  Regular Flex
>> grew just fine and it didn’t support modules in 1.0.
>>
>> For sure, as we add modules, AMF, I18N, we'll gain more customers, but I
>> am hesitant to say these are all 1.0 required features.
>>
>> Thoughts?
>> -Alex
>>
>> On 1/10/17, 6:28 AM, "Dev LFM"  wrote:
>>
>> >+1
>> >
>> >2017-01-10 14:09 GMT+00:00 Fréderic Cox :
>> >
>> >> AMF is also essential for us to take FlexJS serious as a replacement
>>to
>> >> Flex
>> >>
>> >> On Tue, Jan 10, 2017 at 2:41 PM, Vincent  wrote:
>> >>
>> >> > Hello,
>> >> >
>> >> > Same points than Christopher : AMF and modules.
>> >> > The first is essential for us.
>> >> >
>> >> > Vincent.
>> >> >
>> >> >
>> >> >
>> >> > Le 10/01/2017 à 13:07, Christofer Dutz a écrit :
>> >> >
>> >> >> +1 for the AMF and +1 for not-unloadable modules.
>> >> >>
>> >> >> I see it the same way as Carlos. At the moment I see FlexJS as an
>> >> >> opportunity for companies to get out of the dilemma of being stuck
>> >>in a
>> >> >> dead end with their existing Flex applications.
>> >> >> Supporting things like modules and AMF will ease the migration
>>costs
>> >> >> dramatically. Even if AMF might be a touch slower than JSON I
>>still
>> >> think
>> >> >> it’s worth being supported.
>> >> >>
>> >> >> Chris
>> >> >>
>> >> >> Am 10.01.17, 12:14 schrieb "carlos.rov...@gmail.com im Auftrag von
>> >> >> Carlos Rovira" > >> >> carlos.rov...@codeoscopic.com>:
>> >> >>
>> >> >>  "IMO, this has two halves:  non-unloadable modules is
>>relatively
>> >> >> straight
>> >> >>  forward to do.  Unloadable modules will be a ton of work.
>>IIRC,
>> >> >> Flex 1.0
>> >> >>  and I think even Flex 2.x grew its customer base without
>> >>unloadable
>> >> >>  modules."
>> >> >>   If non-unloadable modules is easy to implement, I think
>>it
>> >> >> should go ASAP.
>> >> >>  Then we could left 

Re: [FlexJS] Some things still missing ni FlexJS

[Peter Ent]

Question in-line below.

Thanks,
Peter

On 1/11/17, 4:43 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>I think many people in this thread are saying "No, we'll not go to
>production without AMF and basic module support". IMHO, it would be very
>difficult to say we have 1.0 without that, since AMF/RemoteObject was in
>almost 99% of old Flex SDK, with some HTTPServices and almost no
>WebServices (I mean the MXML object).
>
>As well, for a basic experiment, people could go without modules, but for
>a
>producction App, a basic load of modules is needed.
>
>Then, i18n, Routing, Unit and Functionality testing and so on should come,
>but for me (If I must to choose) that could come after 1.0
>
>For example, in my own company, without AMF and Modules I don't have
>enough
>to put FlexJS over React to ask people to use it over the other... (and I
>know that we'll find many other little things we need in the road)

Are people in your company already using React and if they are, what do
they use to communicate with your backend systems? REST with JSON results?

>
>Just my 2ctns
>
>
>2017-01-10 18:11 GMT+01:00 Alex Harui :
>
>> In my mind, there is little doubt that someone will someday implement
>>AMF
>> and not-unloadable modules.  The question is when?  IMO, as soon as
>> someone can tell us they've gone to production with the code we have,
>>I'm
>> willing to call that 1.0, and the people who wrote that app probably
>> migrated a single SWF, single-language, XML or REST app.  Regular Flex
>> grew just fine and it didn¹t support modules in 1.0.
>>
>> For sure, as we add modules, AMF, I18N, we'll gain more customers, but I
>> am hesitant to say these are all 1.0 required features.
>>
>> Thoughts?
>> -Alex
>>
>> On 1/10/17, 6:28 AM, "Dev LFM"  wrote:
>>
>> >+1
>> >
>> >2017-01-10 14:09 GMT+00:00 Fréderic Cox :
>> >
>> >> AMF is also essential for us to take FlexJS serious as a replacement
>>to
>> >> Flex
>> >>
>> >> On Tue, Jan 10, 2017 at 2:41 PM, Vincent  wrote:
>> >>
>> >> > Hello,
>> >> >
>> >> > Same points than Christopher : AMF and modules.
>> >> > The first is essential for us.
>> >> >
>> >> > Vincent.
>> >> >
>> >> >
>> >> >
>> >> > Le 10/01/2017 à 13:07, Christofer Dutz a écrit :
>> >> >
>> >> >> +1 for the AMF and +1 for not-unloadable modules.
>> >> >>
>> >> >> I see it the same way as Carlos. At the moment I see FlexJS as an
>> >> >> opportunity for companies to get out of the dilemma of being stuck
>> >>in a
>> >> >> dead end with their existing Flex applications.
>> >> >> Supporting things like modules and AMF will ease the migration
>>costs
>> >> >> dramatically. Even if AMF might be a touch slower than JSON I
>>still
>> >> think
>> >> >> it¹s worth being supported.
>> >> >>
>> >> >> Chris
>> >> >>
>> >> >> Am 10.01.17, 12:14 schrieb "carlos.rov...@gmail.com im Auftrag von
>> >> >> Carlos Rovira" > >> >> carlos.rov...@codeoscopic.com>:
>> >> >>
>> >> >>  "IMO, this has two halves:  non-unloadable modules is
>>relatively
>> >> >> straight
>> >> >>  forward to do.  Unloadable modules will be a ton of work.
>>IIRC,
>> >> >> Flex 1.0
>> >> >>  and I think even Flex 2.x grew its customer base without
>> >>unloadable
>> >> >>  modules."
>> >> >>   If non-unloadable modules is easy to implement, I think
>>it
>> >> >> should go ASAP.
>> >> >>  Then we could left unloadable modules por the future...
>> >> >>   For me, AMF is a must, since many companies are using
>>it,
>> >>and
>> >> I
>> >> >> expect many
>> >> >>  of them switch from old Flex to FlexJS if it's as easy as
>>change
>> >> >> only the
>> >> >>  frontend. Change server code means no easy way to change, so
>> >>stick
>> >> >> in old
>> >> >>  code
>> >> >>   Thanks
>> >> >> 2017-01-08 9:52 GMT+01:00 Harbs <
>> >> >> harbs.li...@gmail.com>:
>> >> >>   > I agree that skinning is harder than it should be.
>> >> >>  >
>> >> >>  > For one thing: There¹s too many attributes which are set
>> >> directly.
>> >> >> More
>> >> >>  > extensive use of CSS would make skinning easier.
>> >> >>  >
>> >> >>  > On Jan 8, 2017, at 10:49 AM, Christofer Dutz <
>> >> >> christofer.d...@c-ware.de>
>> >> >>  > wrote:
>> >> >>  >
>> >> >>  > > From my side I¹m missing skinnable components. I really
>> >>loved
>> >> >> the way I
>> >> >>  > could create applications with skinning.
>> >> >>  >
>> >> >>  >
>> >> >>--
>> >> >>   Carlos Rovira
>> >> >>  Director General
>> >> >>  M: +34 607 22 60 05
>> >> >>  http://www.codeoscopic.com
>> >> >>  http://www.avant2.es
>> >> >>   Este mensaje se dirige exclusivamente a su destinatario
>>y
>> >> puede
>> >> >> contener
>> >> >>  

Re: [FlexJS] Some things still missing ni FlexJS

[Christofer Dutz]

I think parsley and similar should be able to run in FlexJS as they don’t rely 
on any UI stuff and as far as I understood it, the concepts they are based on 
should work with FlexJS. Haven’t tried that though ;-)

Chris

Am 11.01.17, 11:04 schrieb "Vincent" :

Hi Carlos,

I agree with you. AMF support is essential for us to start thinking 
porting our Flex apps to FlexJS.

I use MVC architecture with the support of Parsley 3 for :

- Dependency Injection
- Messaging
- Managed command (synchronous and asynchronous)

Is there an equivalent of this tools in the current version of FlexJS ?

Cheers.

Vincent.


Le 11/01/2017 à 10:43, Carlos Rovira a écrit :
> Hi Alex,
>
> I think many people in this thread are saying "No, we'll not go to
> production without AMF and basic module support". IMHO, it would be very
> difficult to say we have 1.0 without that, since AMF/RemoteObject was in
> almost 99% of old Flex SDK, with some HTTPServices and almost no
> WebServices (I mean the MXML object).
>
> As well, for a basic experiment, people could go without modules, but for 
a
> producction App, a basic load of modules is needed.
>
> Then, i18n, Routing, Unit and Functionality testing and so on should come,
> but for me (If I must to choose) that could come after 1.0
>
> For example, in my own company, without AMF and Modules I don't have 
enough
> to put FlexJS over React to ask people to use it over the other... (and I
> know that we'll find many other little things we need in the road)
>
> Just my 2ctns
>
>
> 2017-01-10 18:11 GMT+01:00 Alex Harui :
>
>> In my mind, there is little doubt that someone will someday implement AMF
>> and not-unloadable modules.  The question is when?  IMO, as soon as
>> someone can tell us they've gone to production with the code we have, I'm
>> willing to call that 1.0, and the people who wrote that app probably
>> migrated a single SWF, single-language, XML or REST app.  Regular Flex
>> grew just fine and it didn’t support modules in 1.0.
>>
>> For sure, as we add modules, AMF, I18N, we'll gain more customers, but I
>> am hesitant to say these are all 1.0 required features.
>>
>> Thoughts?
>> -Alex
>>
>> On 1/10/17, 6:28 AM, "Dev LFM"  wrote:
>>
>>> +1
>>>
>>> 2017-01-10 14:09 GMT+00:00 Fréderic Cox :
>>>
 AMF is also essential for us to take FlexJS serious as a replacement to
 Flex

 On Tue, Jan 10, 2017 at 2:41 PM, Vincent  wrote:

> Hello,
>
> Same points than Christopher : AMF and modules.
> The first is essential for us.
>
> Vincent.
>
>
>
> Le 10/01/2017 à 13:07, Christofer Dutz a écrit :
>
>> +1 for the AMF and +1 for not-unloadable modules.
>>
>> I see it the same way as Carlos. At the moment I see FlexJS as an
>> opportunity for companies to get out of the dilemma of being stuck
 in a
>> dead end with their existing Flex applications.
>> Supporting things like modules and AMF will ease the migration costs
>> dramatically. Even if AMF might be a touch slower than JSON I still
 think
>> it’s worth being supported.
>>
>> Chris
>>
>> Am 10.01.17, 12:14 schrieb "carlos.rov...@gmail.com im Auftrag von
>> Carlos Rovira" > carlos.rov...@codeoscopic.com>:
>>
>>   "IMO, this has two halves:  non-unloadable modules is 
relatively
>> straight
>>   forward to do.  Unloadable modules will be a ton of work.  
IIRC,
>> Flex 1.0
>>   and I think even Flex 2.x grew its customer base without
 unloadable
>>   modules."
>>If non-unloadable modules is easy to implement, I think it
>> should go ASAP.
>>   Then we could left unloadable modules por the future...
>>For me, AMF is a must, since many companies are using it,
 and
 I
>> expect many
>>   of them switch from old Flex to FlexJS if it's as easy as 
change
>> only the
>>   frontend. Change server code means no easy way to change, so
 stick
>> in old
>>   code
>>Thanks
>>  2017-01-08 9:52 GMT+01:00 Harbs <
>> harbs.li...@gmail.com>:
>>> I agree that skinning is harder than it should be.
>>   >
>>   > For one thing: There’s too many attributes which are set
 directly.
>> More

Re: [FlexJS] Some things still missing ni FlexJS

[Vincent]

Hi Yishay,

I didn't know that pureMVC had been ported to javascript (and so many 
others langages).

Good to know that there is already an option for MVC framework in FlexJS.

Thanks.

Vincent.


Le 11/01/2017 à 12:22, Yishay Weiss a écrit :

We’re using PureMVC with FlexJS.



From: Vincent<mailto:vinc...@after24.net>
Sent: Wednesday, January 11, 2017 12:04 PM
To: dev@flex.apache.org<mailto:dev@flex.apache.org>
Subject: Re: [FlexJS] Some things still missing ni FlexJS



Hi Carlos,

I agree with you. AMF support is essential for us to start thinking
porting our Flex apps to FlexJS.

I use MVC architecture with the support of Parsley 3 for :

- Dependency Injection
- Messaging
- Managed command (synchronous and asynchronous)

Is there an equivalent of this tools in the current version of FlexJS ?

Cheers.

Vincent.


Le 11/01/2017 à 10:43, Carlos Rovira a écrit :

Hi Alex,

I think many people in this thread are saying "No, we'll not go to
production without AMF and basic module support". IMHO, it would be very
difficult to say we have 1.0 without that, since AMF/RemoteObject was in
almost 99% of old Flex SDK, with some HTTPServices and almost no
WebServices (I mean the MXML object).

As well, for a basic experiment, people could go without modules, but for a
producction App, a basic load of modules is needed.

Then, i18n, Routing, Unit and Functionality testing and so on should come,
but for me (If I must to choose) that could come after 1.0

For example, in my own company, without AMF and Modules I don't have enough
to put FlexJS over React to ask people to use it over the other... (and I
know that we'll find many other little things we need in the road)

Just my 2ctns


2017-01-10 18:11 GMT+01:00 Alex Harui <aha...@adobe.com>:


In my mind, there is little doubt that someone will someday implement AMF
and not-unloadable modules.  The question is when?  IMO, as soon as
someone can tell us they've gone to production with the code we have, I'm
willing to call that 1.0, and the people who wrote that app probably
migrated a single SWF, single-language, XML or REST app.  Regular Flex
grew just fine and it didn’t support modules in 1.0.

For sure, as we add modules, AMF, I18N, we'll gain more customers, but I
am hesitant to say these are all 1.0 required features.

Thoughts?
-Alex

On 1/10/17, 6:28 AM, "Dev LFM" <developer...@gmail.com> wrote:


+1

2017-01-10 14:09 GMT+00:00 Fréderic Cox <coxfrede...@gmail.com>:


AMF is also essential for us to take FlexJS serious as a replacement to
Flex

On Tue, Jan 10, 2017 at 2:41 PM, Vincent <vinc...@after24.net> wrote:


Hello,

Same points than Christopher : AMF and modules.
The first is essential for us.

Vincent.



Le 10/01/2017 à 13:07, Christofer Dutz a écrit :


+1 for the AMF and +1 for not-unloadable modules.

I see it the same way as Carlos. At the moment I see FlexJS as an
opportunity for companies to get out of the dilemma of being stuck

in a

dead end with their existing Flex applications.
Supporting things like modules and AMF will ease the migration costs
dramatically. Even if AMF might be a touch slower than JSON I still

think

it’s worth being supported.

Chris

Am 10.01.17, 12:14 schrieb "carlos.rov...@gmail.com im Auftrag von
Carlos Rovira" <carlos.rov...@gmail.com im Auftrag von
carlos.rov...@codeoscopic.com>:

   "IMO, this has two halves:  non-unloadable modules is relatively
straight
   forward to do.  Unloadable modules will be a ton of work.  IIRC,
Flex 1.0
   and I think even Flex 2.x grew its customer base without

unloadable

   modules."
If non-unloadable modules is easy to implement, I think it
should go ASAP.
   Then we could left unloadable modules por the future...
For me, AMF is a must, since many companies are using it,

and
I

expect many
   of them switch from old Flex to FlexJS if it's as easy as change
only the
   frontend. Change server code means no easy way to change, so

stick

in old
   code
Thanks
  2017-01-08 9:52 GMT+01:00 Harbs <
harbs.li...@gmail.com>:
> I agree that skinning is harder than it should be.
   >
   > For one thing: There’s too many attributes which are set

directly.

More
   > extensive use of CSS would make skinning easier.
   >
   > On Jan 8, 2017, at 10:49 AM, Christofer Dutz <
christofer.d...@c-ware.de>
   > wrote:
   >
   > > From my side I’m missing skinnable components. I really

loved

the way I
   > could create applications with skinning.
   >
   >
 --
Carlos Rovira
   Director General
   M: +34 607 22 60 05
   http://www.codeoscopic.com
   http://www.avant2.es
Este mensaje se dirige exclusivamente a su destinatario y

puede

contener
   información privilegiad

RE: [FlexJS] Some things still missing ni FlexJS

[Yishay Weiss]

We’re using PureMVC with FlexJS.



From: Vincent<mailto:vinc...@after24.net>
Sent: Wednesday, January 11, 2017 12:04 PM
To: dev@flex.apache.org<mailto:dev@flex.apache.org>
Subject: Re: [FlexJS] Some things still missing ni FlexJS



Hi Carlos,

I agree with you. AMF support is essential for us to start thinking
porting our Flex apps to FlexJS.

I use MVC architecture with the support of Parsley 3 for :

- Dependency Injection
- Messaging
- Managed command (synchronous and asynchronous)

Is there an equivalent of this tools in the current version of FlexJS ?

Cheers.

Vincent.


Le 11/01/2017 à 10:43, Carlos Rovira a écrit :
> Hi Alex,
>
> I think many people in this thread are saying "No, we'll not go to
> production without AMF and basic module support". IMHO, it would be very
> difficult to say we have 1.0 without that, since AMF/RemoteObject was in
> almost 99% of old Flex SDK, with some HTTPServices and almost no
> WebServices (I mean the MXML object).
>
> As well, for a basic experiment, people could go without modules, but for a
> producction App, a basic load of modules is needed.
>
> Then, i18n, Routing, Unit and Functionality testing and so on should come,
> but for me (If I must to choose) that could come after 1.0
>
> For example, in my own company, without AMF and Modules I don't have enough
> to put FlexJS over React to ask people to use it over the other... (and I
> know that we'll find many other little things we need in the road)
>
> Just my 2ctns
>
>
> 2017-01-10 18:11 GMT+01:00 Alex Harui <aha...@adobe.com>:
>
>> In my mind, there is little doubt that someone will someday implement AMF
>> and not-unloadable modules.  The question is when?  IMO, as soon as
>> someone can tell us they've gone to production with the code we have, I'm
>> willing to call that 1.0, and the people who wrote that app probably
>> migrated a single SWF, single-language, XML or REST app.  Regular Flex
>> grew just fine and it didn’t support modules in 1.0.
>>
>> For sure, as we add modules, AMF, I18N, we'll gain more customers, but I
>> am hesitant to say these are all 1.0 required features.
>>
>> Thoughts?
>> -Alex
>>
>> On 1/10/17, 6:28 AM, "Dev LFM" <developer...@gmail.com> wrote:
>>
>>> +1
>>>
>>> 2017-01-10 14:09 GMT+00:00 Fréderic Cox <coxfrede...@gmail.com>:
>>>
>>>> AMF is also essential for us to take FlexJS serious as a replacement to
>>>> Flex
>>>>
>>>> On Tue, Jan 10, 2017 at 2:41 PM, Vincent <vinc...@after24.net> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Same points than Christopher : AMF and modules.
>>>>> The first is essential for us.
>>>>>
>>>>> Vincent.
>>>>>
>>>>>
>>>>>
>>>>> Le 10/01/2017 à 13:07, Christofer Dutz a écrit :
>>>>>
>>>>>> +1 for the AMF and +1 for not-unloadable modules.
>>>>>>
>>>>>> I see it the same way as Carlos. At the moment I see FlexJS as an
>>>>>> opportunity for companies to get out of the dilemma of being stuck
>>>> in a
>>>>>> dead end with their existing Flex applications.
>>>>>> Supporting things like modules and AMF will ease the migration costs
>>>>>> dramatically. Even if AMF might be a touch slower than JSON I still
>>>> think
>>>>>> it’s worth being supported.
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>> Am 10.01.17, 12:14 schrieb "carlos.rov...@gmail.com im Auftrag von
>>>>>> Carlos Rovira" <carlos.rov...@gmail.com im Auftrag von
>>>>>> carlos.rov...@codeoscopic.com>:
>>>>>>
>>>>>>   "IMO, this has two halves:  non-unloadable modules is relatively
>>>>>> straight
>>>>>>   forward to do.  Unloadable modules will be a ton of work.  IIRC,
>>>>>> Flex 1.0
>>>>>>   and I think even Flex 2.x grew its customer base without
>>>> unloadable
>>>>>>   modules."
>>>>>>If non-unloadable modules is easy to implement, I think it
>>>>>> should go ASAP.
>>>>>>   Then we could left unloadable modules por the future...
>>>>>>For me, AMF is a must, since many companies are using it,
>>>> and
>>>> I
>>>>>> expect many
>>>>>&

Re: [FlexJS] Some things still missing ni FlexJS

[Carlos Rovira]

Hi Vincent,

I think we don't have nothing yet like Parsely or Swiz. It's clear that we
need many things to be in the same relation as Flex SDK, but my point is to
isolate the problem, so if people want to change, at least make him to
create a completely new interface that affects only to the client, so the
new client has the AMF hooks to connect in the same way as the old Flex
client.

If we tell people that they need to change the server layer, then the
boundaries are greater and many people will even think about it.

We could control in some way the needs of Swiz/Parsely, (and the others)
and start something from scratch that start to pull from our servers and
make an easy transition, without much pain and with time to a new FlexJS
client.



2017-01-11 11:04 GMT+01:00 Vincent :

> Hi Carlos,
>
> I agree with you. AMF support is essential for us to start thinking
> porting our Flex apps to FlexJS.
>
> I use MVC architecture with the support of Parsley 3 for :
>
> - Dependency Injection
> - Messaging
> - Managed command (synchronous and asynchronous)
>
> Is there an equivalent of this tools in the current version of FlexJS ?
>
> Cheers.
>
> Vincent.
>
>
>
> Le 11/01/2017 à 10:43, Carlos Rovira a écrit :
>
>> Hi Alex,
>>
>> I think many people in this thread are saying "No, we'll not go to
>> production without AMF and basic module support". IMHO, it would be very
>> difficult to say we have 1.0 without that, since AMF/RemoteObject was in
>> almost 99% of old Flex SDK, with some HTTPServices and almost no
>> WebServices (I mean the MXML object).
>>
>> As well, for a basic experiment, people could go without modules, but for
>> a
>> producction App, a basic load of modules is needed.
>>
>> Then, i18n, Routing, Unit and Functionality testing and so on should come,
>> but for me (If I must to choose) that could come after 1.0
>>
>> For example, in my own company, without AMF and Modules I don't have
>> enough
>> to put FlexJS over React to ask people to use it over the other... (and I
>> know that we'll find many other little things we need in the road)
>>
>> Just my 2ctns
>>
>>
>> 2017-01-10 18:11 GMT+01:00 Alex Harui :
>>
>> In my mind, there is little doubt that someone will someday implement AMF
>>> and not-unloadable modules.  The question is when?  IMO, as soon as
>>> someone can tell us they've gone to production with the code we have, I'm
>>> willing to call that 1.0, and the people who wrote that app probably
>>> migrated a single SWF, single-language, XML or REST app.  Regular Flex
>>> grew just fine and it didn’t support modules in 1.0.
>>>
>>> For sure, as we add modules, AMF, I18N, we'll gain more customers, but I
>>> am hesitant to say these are all 1.0 required features.
>>>
>>> Thoughts?
>>> -Alex
>>>
>>> On 1/10/17, 6:28 AM, "Dev LFM"  wrote:
>>>
>>> +1

 2017-01-10 14:09 GMT+00:00 Fréderic Cox :

 AMF is also essential for us to take FlexJS serious as a replacement to
> Flex
>
> On Tue, Jan 10, 2017 at 2:41 PM, Vincent  wrote:
>
> Hello,
>>
>> Same points than Christopher : AMF and modules.
>> The first is essential for us.
>>
>> Vincent.
>>
>>
>>
>> Le 10/01/2017 à 13:07, Christofer Dutz a écrit :
>>
>> +1 for the AMF and +1 for not-unloadable modules.
>>>
>>> I see it the same way as Carlos. At the moment I see FlexJS as an
>>> opportunity for companies to get out of the dilemma of being stuck
>>>
>> in a
>
>> dead end with their existing Flex applications.
>>> Supporting things like modules and AMF will ease the migration costs
>>> dramatically. Even if AMF might be a touch slower than JSON I still
>>>
>> think
>
>> it’s worth being supported.
>>>
>>> Chris
>>>
>>> Am 10.01.17, 12:14 schrieb "carlos.rov...@gmail.com im Auftrag von
>>> Carlos Rovira" >> carlos.rov...@codeoscopic.com>:
>>>
>>>   "IMO, this has two halves:  non-unloadable modules is
>>> relatively
>>> straight
>>>   forward to do.  Unloadable modules will be a ton of work.
>>> IIRC,
>>> Flex 1.0
>>>   and I think even Flex 2.x grew its customer base without
>>>
>> unloadable
>
>>   modules."
>>>If non-unloadable modules is easy to implement, I think it
>>> should go ASAP.
>>>   Then we could left unloadable modules por the future...
>>>For me, AMF is a must, since many companies are using it,
>>>
>> and
> I
>
>> expect many
>>>   of them switch from old Flex to FlexJS if it's as easy as
>>> change
>>> only the
>>>   frontend. Change server code means no easy way to change, so
>>>
>> stick
>
>> in old
>>>   code
>>>Thanks
>>> 

Re: [FlexJS] Some things still missing ni FlexJS

[Vincent]

Hi Carlos,

I agree with you. AMF support is essential for us to start thinking 
porting our Flex apps to FlexJS.


I use MVC architecture with the support of Parsley 3 for :

- Dependency Injection
- Messaging
- Managed command (synchronous and asynchronous)

Is there an equivalent of this tools in the current version of FlexJS ?

Cheers.

Vincent.


Le 11/01/2017 à 10:43, Carlos Rovira a écrit :

Hi Alex,

I think many people in this thread are saying "No, we'll not go to
production without AMF and basic module support". IMHO, it would be very
difficult to say we have 1.0 without that, since AMF/RemoteObject was in
almost 99% of old Flex SDK, with some HTTPServices and almost no
WebServices (I mean the MXML object).

As well, for a basic experiment, people could go without modules, but for a
producction App, a basic load of modules is needed.

Then, i18n, Routing, Unit and Functionality testing and so on should come,
but for me (If I must to choose) that could come after 1.0

For example, in my own company, without AMF and Modules I don't have enough
to put FlexJS over React to ask people to use it over the other... (and I
know that we'll find many other little things we need in the road)

Just my 2ctns


2017-01-10 18:11 GMT+01:00 Alex Harui :


In my mind, there is little doubt that someone will someday implement AMF
and not-unloadable modules.  The question is when?  IMO, as soon as
someone can tell us they've gone to production with the code we have, I'm
willing to call that 1.0, and the people who wrote that app probably
migrated a single SWF, single-language, XML or REST app.  Regular Flex
grew just fine and it didn’t support modules in 1.0.

For sure, as we add modules, AMF, I18N, we'll gain more customers, but I
am hesitant to say these are all 1.0 required features.

Thoughts?
-Alex

On 1/10/17, 6:28 AM, "Dev LFM"  wrote:


+1

2017-01-10 14:09 GMT+00:00 Fréderic Cox :


AMF is also essential for us to take FlexJS serious as a replacement to
Flex

On Tue, Jan 10, 2017 at 2:41 PM, Vincent  wrote:


Hello,

Same points than Christopher : AMF and modules.
The first is essential for us.

Vincent.



Le 10/01/2017 à 13:07, Christofer Dutz a écrit :


+1 for the AMF and +1 for not-unloadable modules.

I see it the same way as Carlos. At the moment I see FlexJS as an
opportunity for companies to get out of the dilemma of being stuck

in a

dead end with their existing Flex applications.
Supporting things like modules and AMF will ease the migration costs
dramatically. Even if AMF might be a touch slower than JSON I still

think

it’s worth being supported.

Chris

Am 10.01.17, 12:14 schrieb "carlos.rov...@gmail.com im Auftrag von
Carlos Rovira" :

  "IMO, this has two halves:  non-unloadable modules is relatively
straight
  forward to do.  Unloadable modules will be a ton of work.  IIRC,
Flex 1.0
  and I think even Flex 2.x grew its customer base without

unloadable

  modules."
   If non-unloadable modules is easy to implement, I think it
should go ASAP.
  Then we could left unloadable modules por the future...
   For me, AMF is a must, since many companies are using it,

and
I

expect many
  of them switch from old Flex to FlexJS if it's as easy as change
only the
  frontend. Change server code means no easy way to change, so

stick

in old
  code
   Thanks
 2017-01-08 9:52 GMT+01:00 Harbs <
harbs.li...@gmail.com>:
   > I agree that skinning is harder than it should be.
  >
  > For one thing: There’s too many attributes which are set

directly.

More
  > extensive use of CSS would make skinning easier.
  >
  > On Jan 8, 2017, at 10:49 AM, Christofer Dutz <
christofer.d...@c-ware.de>
  > wrote:
  >
  > > From my side I’m missing skinnable components. I really

loved

the way I
  > could create applications with skinning.
  >
  >
--
   Carlos Rovira
  Director General
  M: +34 607 22 60 05
  http://www.codeoscopic.com
  http://www.avant2.es
   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

Re: [FlexJS] Some things still missing ni FlexJS

[Carlos Rovira]

Hi Alex,

I think many people in this thread are saying "No, we'll not go to
production without AMF and basic module support". IMHO, it would be very
difficult to say we have 1.0 without that, since AMF/RemoteObject was in
almost 99% of old Flex SDK, with some HTTPServices and almost no
WebServices (I mean the MXML object).

As well, for a basic experiment, people could go without modules, but for a
producction App, a basic load of modules is needed.

Then, i18n, Routing, Unit and Functionality testing and so on should come,
but for me (If I must to choose) that could come after 1.0

For example, in my own company, without AMF and Modules I don't have enough
to put FlexJS over React to ask people to use it over the other... (and I
know that we'll find many other little things we need in the road)

Just my 2ctns


2017-01-10 18:11 GMT+01:00 Alex Harui :

> In my mind, there is little doubt that someone will someday implement AMF
> and not-unloadable modules.  The question is when?  IMO, as soon as
> someone can tell us they've gone to production with the code we have, I'm
> willing to call that 1.0, and the people who wrote that app probably
> migrated a single SWF, single-language, XML or REST app.  Regular Flex
> grew just fine and it didn’t support modules in 1.0.
>
> For sure, as we add modules, AMF, I18N, we'll gain more customers, but I
> am hesitant to say these are all 1.0 required features.
>
> Thoughts?
> -Alex
>
> On 1/10/17, 6:28 AM, "Dev LFM"  wrote:
>
> >+1
> >
> >2017-01-10 14:09 GMT+00:00 Fréderic Cox :
> >
> >> AMF is also essential for us to take FlexJS serious as a replacement to
> >> Flex
> >>
> >> On Tue, Jan 10, 2017 at 2:41 PM, Vincent  wrote:
> >>
> >> > Hello,
> >> >
> >> > Same points than Christopher : AMF and modules.
> >> > The first is essential for us.
> >> >
> >> > Vincent.
> >> >
> >> >
> >> >
> >> > Le 10/01/2017 à 13:07, Christofer Dutz a écrit :
> >> >
> >> >> +1 for the AMF and +1 for not-unloadable modules.
> >> >>
> >> >> I see it the same way as Carlos. At the moment I see FlexJS as an
> >> >> opportunity for companies to get out of the dilemma of being stuck
> >>in a
> >> >> dead end with their existing Flex applications.
> >> >> Supporting things like modules and AMF will ease the migration costs
> >> >> dramatically. Even if AMF might be a touch slower than JSON I still
> >> think
> >> >> it’s worth being supported.
> >> >>
> >> >> Chris
> >> >>
> >> >> Am 10.01.17, 12:14 schrieb "carlos.rov...@gmail.com im Auftrag von
> >> >> Carlos Rovira"  >> >> carlos.rov...@codeoscopic.com>:
> >> >>
> >> >>  "IMO, this has two halves:  non-unloadable modules is relatively
> >> >> straight
> >> >>  forward to do.  Unloadable modules will be a ton of work.  IIRC,
> >> >> Flex 1.0
> >> >>  and I think even Flex 2.x grew its customer base without
> >>unloadable
> >> >>  modules."
> >> >>   If non-unloadable modules is easy to implement, I think it
> >> >> should go ASAP.
> >> >>  Then we could left unloadable modules por the future...
> >> >>   For me, AMF is a must, since many companies are using it,
> >>and
> >> I
> >> >> expect many
> >> >>  of them switch from old Flex to FlexJS if it's as easy as change
> >> >> only the
> >> >>  frontend. Change server code means no easy way to change, so
> >>stick
> >> >> in old
> >> >>  code
> >> >>   Thanks
> >> >> 2017-01-08 9:52 GMT+01:00 Harbs <
> >> >> harbs.li...@gmail.com>:
> >> >>   > I agree that skinning is harder than it should be.
> >> >>  >
> >> >>  > For one thing: There’s too many attributes which are set
> >> directly.
> >> >> More
> >> >>  > extensive use of CSS would make skinning easier.
> >> >>  >
> >> >>  > On Jan 8, 2017, at 10:49 AM, Christofer Dutz <
> >> >> christofer.d...@c-ware.de>
> >> >>  > wrote:
> >> >>  >
> >> >>  > > From my side I’m missing skinnable components. I really
> >>loved
> >> >> the way I
> >> >>  > could create applications with skinning.
> >> >>  >
> >> >>  >
> >> >>--
> >> >>   Carlos Rovira
> >> >>  Director General
> >> >>  M: +34 607 22 60 05
> >> >>  http://www.codeoscopic.com
> >> >>  http://www.avant2.es
> >> >>   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 

Re: [FlexJS] Some things still missing ni FlexJS

[Alex Harui]

In my mind, there is little doubt that someone will someday implement AMF
and not-unloadable modules.  The question is when?  IMO, as soon as
someone can tell us they've gone to production with the code we have, I'm
willing to call that 1.0, and the people who wrote that app probably
migrated a single SWF, single-language, XML or REST app.  Regular Flex
grew just fine and it didn’t support modules in 1.0.

For sure, as we add modules, AMF, I18N, we'll gain more customers, but I
am hesitant to say these are all 1.0 required features.

Thoughts?
-Alex

On 1/10/17, 6:28 AM, "Dev LFM"  wrote:

>+1
>
>2017-01-10 14:09 GMT+00:00 Fréderic Cox :
>
>> AMF is also essential for us to take FlexJS serious as a replacement to
>> Flex
>>
>> On Tue, Jan 10, 2017 at 2:41 PM, Vincent  wrote:
>>
>> > Hello,
>> >
>> > Same points than Christopher : AMF and modules.
>> > The first is essential for us.
>> >
>> > Vincent.
>> >
>> >
>> >
>> > Le 10/01/2017 à 13:07, Christofer Dutz a écrit :
>> >
>> >> +1 for the AMF and +1 for not-unloadable modules.
>> >>
>> >> I see it the same way as Carlos. At the moment I see FlexJS as an
>> >> opportunity for companies to get out of the dilemma of being stuck
>>in a
>> >> dead end with their existing Flex applications.
>> >> Supporting things like modules and AMF will ease the migration costs
>> >> dramatically. Even if AMF might be a touch slower than JSON I still
>> think
>> >> it’s worth being supported.
>> >>
>> >> Chris
>> >>
>> >> Am 10.01.17, 12:14 schrieb "carlos.rov...@gmail.com im Auftrag von
>> >> Carlos Rovira" > >> carlos.rov...@codeoscopic.com>:
>> >>
>> >>  "IMO, this has two halves:  non-unloadable modules is relatively
>> >> straight
>> >>  forward to do.  Unloadable modules will be a ton of work.  IIRC,
>> >> Flex 1.0
>> >>  and I think even Flex 2.x grew its customer base without
>>unloadable
>> >>  modules."
>> >>   If non-unloadable modules is easy to implement, I think it
>> >> should go ASAP.
>> >>  Then we could left unloadable modules por the future...
>> >>   For me, AMF is a must, since many companies are using it,
>>and
>> I
>> >> expect many
>> >>  of them switch from old Flex to FlexJS if it's as easy as change
>> >> only the
>> >>  frontend. Change server code means no easy way to change, so
>>stick
>> >> in old
>> >>  code
>> >>   Thanks
>> >> 2017-01-08 9:52 GMT+01:00 Harbs <
>> >> harbs.li...@gmail.com>:
>> >>   > I agree that skinning is harder than it should be.
>> >>  >
>> >>  > For one thing: There’s too many attributes which are set
>> directly.
>> >> More
>> >>  > extensive use of CSS would make skinning easier.
>> >>  >
>> >>  > On Jan 8, 2017, at 10:49 AM, Christofer Dutz <
>> >> christofer.d...@c-ware.de>
>> >>  > wrote:
>> >>  >
>> >>  > > From my side I’m missing skinnable components. I really
>>loved
>> >> the way I
>> >>  > could create applications with skinning.
>> >>  >
>> >>  >
>> >>--
>> >>   Carlos Rovira
>> >>  Director General
>> >>  M: +34 607 22 60 05
>> >>  http://www.codeoscopic.com
>> >>  http://www.avant2.es
>> >>   Este mensaje se dirige exclusivamente a su destinatario y
>> puede
>> >> contener
>> >>  información privilegiada o confidencial. Si ha recibido este
>> mensaje
>> >> por
>> >>  error, le rogamos que nos lo comunique inmediatamente por esta
>> misma
>> >> vía y
>> >>  proceda a su destrucción.
>> >>   De la vigente Ley Orgánica de Protección de Datos
>>(15/1999),
>> le
>> >> comunicamos
>> >>  que sus datos forman parte de un fichero cuyo responsable es
>> >> CODEOSCOPIC
>> >>  S.A. La finalidad de dicho tratamiento es facilitar la
>>prestación
>> del
>> >>  servicio o información solicitados, teniendo usted derecho de
>> acceso,
>> >>  rectificación, cancelación y oposición de sus datos
>>dirigiéndose a
>> >> nuestras
>> >>  oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la
>> >> documentación
>> >>  necesaria.
>> >>
>> >>
>> >
>> >
>>

Re: [FlexJS] Some things still missing ni FlexJS

[Dev LFM]

+1

2017-01-10 14:09 GMT+00:00 Fréderic Cox :

> AMF is also essential for us to take FlexJS serious as a replacement to
> Flex
>
> On Tue, Jan 10, 2017 at 2:41 PM, Vincent  wrote:
>
> > Hello,
> >
> > Same points than Christopher : AMF and modules.
> > The first is essential for us.
> >
> > Vincent.
> >
> >
> >
> > Le 10/01/2017 à 13:07, Christofer Dutz a écrit :
> >
> >> +1 for the AMF and +1 for not-unloadable modules.
> >>
> >> I see it the same way as Carlos. At the moment I see FlexJS as an
> >> opportunity for companies to get out of the dilemma of being stuck in a
> >> dead end with their existing Flex applications.
> >> Supporting things like modules and AMF will ease the migration costs
> >> dramatically. Even if AMF might be a touch slower than JSON I still
> think
> >> it’s worth being supported.
> >>
> >> Chris
> >>
> >> Am 10.01.17, 12:14 schrieb "carlos.rov...@gmail.com im Auftrag von
> >> Carlos Rovira"  >> carlos.rov...@codeoscopic.com>:
> >>
> >>  "IMO, this has two halves:  non-unloadable modules is relatively
> >> straight
> >>  forward to do.  Unloadable modules will be a ton of work.  IIRC,
> >> Flex 1.0
> >>  and I think even Flex 2.x grew its customer base without unloadable
> >>  modules."
> >>   If non-unloadable modules is easy to implement, I think it
> >> should go ASAP.
> >>  Then we could left unloadable modules por the future...
> >>   For me, AMF is a must, since many companies are using it, and
> I
> >> expect many
> >>  of them switch from old Flex to FlexJS if it's as easy as change
> >> only the
> >>  frontend. Change server code means no easy way to change, so stick
> >> in old
> >>  code
> >>   Thanks
> >> 2017-01-08 9:52 GMT+01:00 Harbs <
> >> harbs.li...@gmail.com>:
> >>   > I agree that skinning is harder than it should be.
> >>  >
> >>  > For one thing: There’s too many attributes which are set
> directly.
> >> More
> >>  > extensive use of CSS would make skinning easier.
> >>  >
> >>  > On Jan 8, 2017, at 10:49 AM, Christofer Dutz <
> >> christofer.d...@c-ware.de>
> >>  > wrote:
> >>  >
> >>  > > From my side I’m missing skinnable components. I really loved
> >> the way I
> >>  > could create applications with skinning.
> >>  >
> >>  >
> >>--
> >>   Carlos Rovira
> >>  Director General
> >>  M: +34 607 22 60 05
> >>  http://www.codeoscopic.com
> >>  http://www.avant2.es
> >>   Este mensaje se dirige exclusivamente a su destinatario y
> puede
> >> contener
> >>  información privilegiada o confidencial. Si ha recibido este
> mensaje
> >> por
> >>  error, le rogamos que nos lo comunique inmediatamente por esta
> misma
> >> vía y
> >>  proceda a su destrucción.
> >>   De la vigente Ley Orgánica de Protección de Datos (15/1999),
> le
> >> comunicamos
> >>  que sus datos forman parte de un fichero cuyo responsable es
> >> CODEOSCOPIC
> >>  S.A. La finalidad de dicho tratamiento es facilitar la prestación
> del
> >>  servicio o información solicitados, teniendo usted derecho de
> acceso,
> >>  rectificación, cancelación y oposición de sus datos dirigiéndose a
> >> nuestras
> >>  oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la
> >> documentación
> >>  necesaria.
> >>
> >>
> >
> >
>

Re: [FlexJS] Some things still missing ni FlexJS

[Fréderic Cox]

AMF is also essential for us to take FlexJS serious as a replacement to Flex

On Tue, Jan 10, 2017 at 2:41 PM, Vincent  wrote:

> Hello,
>
> Same points than Christopher : AMF and modules.
> The first is essential for us.
>
> Vincent.
>
>
>
> Le 10/01/2017 à 13:07, Christofer Dutz a écrit :
>
>> +1 for the AMF and +1 for not-unloadable modules.
>>
>> I see it the same way as Carlos. At the moment I see FlexJS as an
>> opportunity for companies to get out of the dilemma of being stuck in a
>> dead end with their existing Flex applications.
>> Supporting things like modules and AMF will ease the migration costs
>> dramatically. Even if AMF might be a touch slower than JSON I still think
>> it’s worth being supported.
>>
>> Chris
>>
>> Am 10.01.17, 12:14 schrieb "carlos.rov...@gmail.com im Auftrag von
>> Carlos Rovira" > carlos.rov...@codeoscopic.com>:
>>
>>  "IMO, this has two halves:  non-unloadable modules is relatively
>> straight
>>  forward to do.  Unloadable modules will be a ton of work.  IIRC,
>> Flex 1.0
>>  and I think even Flex 2.x grew its customer base without unloadable
>>  modules."
>>   If non-unloadable modules is easy to implement, I think it
>> should go ASAP.
>>  Then we could left unloadable modules por the future...
>>   For me, AMF is a must, since many companies are using it, and I
>> expect many
>>  of them switch from old Flex to FlexJS if it's as easy as change
>> only the
>>  frontend. Change server code means no easy way to change, so stick
>> in old
>>  code
>>   Thanks
>> 2017-01-08 9:52 GMT+01:00 Harbs <
>> harbs.li...@gmail.com>:
>>   > I agree that skinning is harder than it should be.
>>  >
>>  > For one thing: There’s too many attributes which are set directly.
>> More
>>  > extensive use of CSS would make skinning easier.
>>  >
>>  > On Jan 8, 2017, at 10:49 AM, Christofer Dutz <
>> christofer.d...@c-ware.de>
>>  > wrote:
>>  >
>>  > > From my side I’m missing skinnable components. I really loved
>> the way I
>>  > could create applications with skinning.
>>  >
>>  >
>>--
>>   Carlos Rovira
>>  Director General
>>  M: +34 607 22 60 05
>>  http://www.codeoscopic.com
>>  http://www.avant2.es
>>   Este mensaje se dirige exclusivamente a su destinatario y puede
>> contener
>>  información privilegiada o confidencial. Si ha recibido este mensaje
>> por
>>  error, le rogamos que nos lo comunique inmediatamente por esta misma
>> vía y
>>  proceda a su destrucción.
>>   De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>> comunicamos
>>  que sus datos forman parte de un fichero cuyo responsable es
>> CODEOSCOPIC
>>  S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>>  servicio o información solicitados, teniendo usted derecho de acceso,
>>  rectificación, cancelación y oposición de sus datos dirigiéndose a
>> nuestras
>>  oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la
>> documentación
>>  necesaria.
>>
>>
>
>

Re: [FlexJS] Some things still missing ni FlexJS

[Vincent]

Hello,

Same points than Christopher : AMF and modules.
The first is essential for us.

Vincent.


Le 10/01/2017 à 13:07, Christofer Dutz a écrit :

+1 for the AMF and +1 for not-unloadable modules.

I see it the same way as Carlos. At the moment I see FlexJS as an opportunity 
for companies to get out of the dilemma of being stuck in a dead end with their 
existing Flex applications.
Supporting things like modules and AMF will ease the migration costs 
dramatically. Even if AMF might be a touch slower than JSON I still think it’s 
worth being supported.

Chris

Am 10.01.17, 12:14 schrieb "carlos.rov...@gmail.com im Auftrag von Carlos Rovira" 
:

 "IMO, this has two halves:  non-unloadable modules is relatively straight
 forward to do.  Unloadable modules will be a ton of work.  IIRC, Flex 1.0
 and I think even Flex 2.x grew its customer base without unloadable
 modules."
 
 If non-unloadable modules is easy to implement, I think it should go ASAP.

 Then we could left unloadable modules por the future...
 
 For me, AMF is a must, since many companies are using it, and I expect many

 of them switch from old Flex to FlexJS if it's as easy as change only the
 frontend. Change server code means no easy way to change, so stick in old
 code
 
 Thanks
 
 
 
 2017-01-08 9:52 GMT+01:00 Harbs :
 
 > I agree that skinning is harder than it should be.

 >
 > For one thing: There’s too many attributes which are set directly. More
 > extensive use of CSS would make skinning easier.
 >
 > On Jan 8, 2017, at 10:49 AM, Christofer Dutz 
 > wrote:
 >
 > > From my side I’m missing skinnable components. I really loved the way I
 > could create applications with skinning.
 >
 >
 
 
 --
 
 Carlos Rovira

 Director General
 M: +34 607 22 60 05
 http://www.codeoscopic.com
 http://www.avant2.es
 
 Este mensaje se dirige exclusivamente a su destinatario y puede contener

 información privilegiada o confidencial. Si ha recibido este mensaje por
 error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
 proceda a su destrucción.
 
 De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos

 que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
 S.A. La finalidad de dicho tratamiento es facilitar la prestación del
 servicio o información solicitados, teniendo usted derecho de acceso,
 rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
 oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
 necesaria.
 

Re: [FlexJS] Some things still missing ni FlexJS

[Carlos Rovira]

The problem with AMF could be what Alex mentioned some time ago. If there's
some C++ code in Flash Player that was making the magic behind scenes for a
super efficient protocol, and if we can super pass this problem in this era
of "no-plugins". We'll need to know what's the effort behind AMF, If
consists in implement the RemoteObject AS3 library for FlexJS (migrate from
Flex SDK), or this can not be done due to that obscure code in flash player
that Alex mention...

about Modules...I think is clear that a quick and useful impl should be
done ASAP, and starting to test in our examples...

Thanks




2017-01-10 13:07 GMT+01:00 Christofer Dutz :

> +1 for the AMF and +1 for not-unloadable modules.
>
> I see it the same way as Carlos. At the moment I see FlexJS as an
> opportunity for companies to get out of the dilemma of being stuck in a
> dead end with their existing Flex applications.
> Supporting things like modules and AMF will ease the migration costs
> dramatically. Even if AMF might be a touch slower than JSON I still think
> it’s worth being supported.
>
> Chris
>
> Am 10.01.17, 12:14 schrieb "carlos.rov...@gmail.com im Auftrag von Carlos
> Rovira"  carlos.rov...@codeoscopic.com>:
>
> "IMO, this has two halves:  non-unloadable modules is relatively
> straight
> forward to do.  Unloadable modules will be a ton of work.  IIRC, Flex
> 1.0
> and I think even Flex 2.x grew its customer base without unloadable
> modules."
>
> If non-unloadable modules is easy to implement, I think it should go
> ASAP.
> Then we could left unloadable modules por the future...
>
> For me, AMF is a must, since many companies are using it, and I expect
> many
> of them switch from old Flex to FlexJS if it's as easy as change only
> the
> frontend. Change server code means no easy way to change, so stick in
> old
> code
>
> Thanks
>
>
>
> 2017-01-08 9:52 GMT+01:00 Harbs :
>
> > I agree that skinning is harder than it should be.
> >
> > For one thing: There’s too many attributes which are set directly.
> More
> > extensive use of CSS would make skinning easier.
> >
> > On Jan 8, 2017, at 10:49 AM, Christofer Dutz <
> christofer.d...@c-ware.de>
> > wrote:
> >
> > > From my side I’m missing skinnable components. I really loved the
> way I
> > could create applications with skinning.
> >
> >
>
>
> --
>
> Carlos Rovira
> Director General
> M: +34 607 22 60 05
> http://www.codeoscopic.com
> http://www.avant2.es
>
> 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.
>
>
>


-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS] Some things still missing ni FlexJS

[Christofer Dutz]

+1 for the AMF and +1 for not-unloadable modules.

I see it the same way as Carlos. At the moment I see FlexJS as an opportunity 
for companies to get out of the dilemma of being stuck in a dead end with their 
existing Flex applications.
Supporting things like modules and AMF will ease the migration costs 
dramatically. Even if AMF might be a touch slower than JSON I still think it’s 
worth being supported.

Chris

Am 10.01.17, 12:14 schrieb "carlos.rov...@gmail.com im Auftrag von Carlos 
Rovira" :

"IMO, this has two halves:  non-unloadable modules is relatively straight
forward to do.  Unloadable modules will be a ton of work.  IIRC, Flex 1.0
and I think even Flex 2.x grew its customer base without unloadable
modules."

If non-unloadable modules is easy to implement, I think it should go ASAP.
Then we could left unloadable modules por the future...

For me, AMF is a must, since many companies are using it, and I expect many
of them switch from old Flex to FlexJS if it's as easy as change only the
frontend. Change server code means no easy way to change, so stick in old
code

Thanks



2017-01-08 9:52 GMT+01:00 Harbs :

> I agree that skinning is harder than it should be.
>
> For one thing: There’s too many attributes which are set directly. More
> extensive use of CSS would make skinning easier.
>
> On Jan 8, 2017, at 10:49 AM, Christofer Dutz 
> wrote:
>
> > From my side I’m missing skinnable components. I really loved the way I
> could create applications with skinning.
>
>


-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS] Some things still missing ni FlexJS

[Carlos Rovira]

"IMO, this has two halves:  non-unloadable modules is relatively straight
forward to do.  Unloadable modules will be a ton of work.  IIRC, Flex 1.0
and I think even Flex 2.x grew its customer base without unloadable
modules."

If non-unloadable modules is easy to implement, I think it should go ASAP.
Then we could left unloadable modules por the future...

For me, AMF is a must, since many companies are using it, and I expect many
of them switch from old Flex to FlexJS if it's as easy as change only the
frontend. Change server code means no easy way to change, so stick in old
code

Thanks



2017-01-08 9:52 GMT+01:00 Harbs :

> I agree that skinning is harder than it should be.
>
> For one thing: There’s too many attributes which are set directly. More
> extensive use of CSS would make skinning easier.
>
> On Jan 8, 2017, at 10:49 AM, Christofer Dutz 
> wrote:
>
> > From my side I’m missing skinnable components. I really loved the way I
> could create applications with skinning.
>
>


-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS] Some things still missing ni FlexJS

[Harbs]

I agree that skinning is harder than it should be.

For one thing: There’s too many attributes which are set directly. More 
extensive use of CSS would make skinning easier.

On Jan 8, 2017, at 10:49 AM, Christofer Dutz  wrote:

> From my side I’m missing skinnable components. I really loved the way I could 
> create applications with skinning.

AW: [FlexJS] Some things still missing ni FlexJS

[Christofer Dutz]

>From my side I’m missing skinnable components. I really loved the way I could 
>create applications with skinning.



Regarding the unit-testing: I was planning on starting work on FlexUnit Support 
in FlexJS, first probably simple Unit-Tests without UI Automation. I guess 
quite some work will have to go into that. But I was assuming the JavaScript 
Support should be quite straight Forward. Also I would be extending the Maven 
plugin to work similar to Flexmojos now to compile and execute the Tests 
automatically as part of a normal build.



For the Integration-Tests I too would see Selenium as the tool of choice. I 
think this should allready work. The only difference is, that These Tests are 
normally written in Java, so as I see it, we would Need to add Java compilation 
for the Tests to the pom as well es a failsafe-plugin (Integration-test-plugin) 
configuration to run These Tests. I was planning on working on this in order to 
create rudimentary Tests for the examples.



Chris





Gesendet von Mail<https://go.microsoft.com/fwlink/?LinkId=550986> für Windows 10



Von: Yishay Weiss<mailto:yishayj...@hotmail.com>
Gesendet: Sonntag, 8. Januar 2017 09:29
An: Harbs<mailto:harbs.li...@gmail.com>; 
dev@flex.apache.org<mailto:dev@flex.apache.org>
Betreff: RE: [FlexJS] Some things still missing ni FlexJS



Two things that spring to my mind are intuitive layouts and stability.





From: Harbs<mailto:harbs.li...@gmail.com>
Sent: Sunday, January 8, 2017 10:18 AM
To: dev@flex.apache.org<mailto:dev@flex.apache.org>
Subject: Re: [FlexJS] Some things still missing ni FlexJS



There’s one thing missing which was not really in the old Flex (or maybe yes 
with the history scripts), but I think is really important for any single page 
javascript application framework:

Routing (or what was called “deep linking” in older terms).

On Jan 7, 2017, at 5:58 PM, Carlos Rovira <carlosrov...@apache.org> wrote:

> Hi,
>
> I want to list some things I miss from old Flex SDK in FlexJS. Hope others
> could bring more if they want. Hope this thread could help us to know what
> people things about it, if someone expect to implement it:
>
> * Modules (or how to make FlexJS load discrete parts and not the all the
> App at once. For example, in MDL I'd like to load the different panel
> examples as I click on tabs on demand...)
>
> * Forms and Validation (currently there's a js:Form prepared for the
> minimum requirements for HTML but not for SWF)
>
> * AMF / RemoteObject
>
> more? ...
>
> --
> Carlos Rovira
> http://about.me/carlosrovira

RE: [FlexJS] Some things still missing ni FlexJS

[Yishay Weiss]

Two things that spring to my mind are intuitive layouts and stability.





From: Harbs<mailto:harbs.li...@gmail.com>
Sent: Sunday, January 8, 2017 10:18 AM
To: dev@flex.apache.org<mailto:dev@flex.apache.org>
Subject: Re: [FlexJS] Some things still missing ni FlexJS



There’s one thing missing which was not really in the old Flex (or maybe yes 
with the history scripts), but I think is really important for any single page 
javascript application framework:

Routing (or what was called “deep linking” in older terms).

On Jan 7, 2017, at 5:58 PM, Carlos Rovira <carlosrov...@apache.org> wrote:

> Hi,
>
> I want to list some things I miss from old Flex SDK in FlexJS. Hope others
> could bring more if they want. Hope this thread could help us to know what
> people things about it, if someone expect to implement it:
>
> * Modules (or how to make FlexJS load discrete parts and not the all the
> App at once. For example, in MDL I'd like to load the different panel
> examples as I click on tabs on demand...)
>
> * Forms and Validation (currently there's a js:Form prepared for the
> minimum requirements for HTML but not for SWF)
>
> * AMF / RemoteObject
>
> more? ...
>
> --
> Carlos Rovira
> http://about.me/carlosrovira

Re: [FlexJS] Some things still missing ni FlexJS

[Harbs]

There’s one thing missing which was not really in the old Flex (or maybe yes 
with the history scripts), but I think is really important for any single page 
javascript application framework:

Routing (or what was called “deep linking” in older terms).

On Jan 7, 2017, at 5:58 PM, Carlos Rovira  wrote:

> Hi,
> 
> I want to list some things I miss from old Flex SDK in FlexJS. Hope others
> could bring more if they want. Hope this thread could help us to know what
> people things about it, if someone expect to implement it:
> 
> * Modules (or how to make FlexJS load discrete parts and not the all the
> App at once. For example, in MDL I'd like to load the different panel
> examples as I click on tabs on demand...)
> 
> * Forms and Validation (currently there's a js:Form prepared for the
> minimum requirements for HTML but not for SWF)
> 
> * AMF / RemoteObject
> 
> more? ...
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: [FlexJS] Some things still missing ni FlexJS

[OmPrakash Muppirala]

On Sat, Jan 7, 2017 at 10:47 AM, Carlos Rovira <
carlos.rov...@codeoscopic.com> wrote:

> Hi Om,
>
> about Yeoman, I didn't know about that, but it seems to me the same as a
> Maven Arquetype to generate a project scaffold.
> Right? If is this, we have already 3 of them (created by Chris, and we
> could make more)
>

That's good to know.  I will try to take a look at the archetype project to
see if we can reuse it for yeoman.

Thanks,
Om


>
> 2017-01-07 18:42 GMT+01:00 OmPrakash Muppirala :
>
> > On Jan 7, 2017 7:59 AM, "Carlos Rovira"  wrote:
> >
> > Hi,
> >
> > I want to list some things I miss from old Flex SDK in FlexJS. Hope
> others
> > could bring more if they want. Hope this thread could help us to know
> what
> > people things about it, if someone expect to implement it:
> >
> > * Modules (or how to make FlexJS load discrete parts and not the all the
> > App at once. For example, in MDL I'd like to load the different panel
> > examples as I click on tabs on demand...)
> >
> > * Forms and Validation (currently there's a js:Form prepared for the
> > minimum requirements for HTML but not for SWF)
> >
> > * AMF / RemoteObject
> >
> >
> >
> >
> > * Unit testing framework (karma, jasmine)
> >
> > * More charts (highcharts integration would be great)
> >
> > * Yeoman integration (yo flexjs basic | mdl)
> >
> > * i18n, i10n
> >
> > * server side rendering  (phantomjs)
> >
> > * Automated functuonal testing (selenium,  riatest, etc)
> >
> >
> > more? ...
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
>
> --
>
> Carlos Rovira
> Director General
> M: +34 607 22 60 05
> http://www.codeoscopic.com
> http://www.avant2.es
>
> Este mensaje se dirige exclusivamente a su destinatario y puede contener
> información privilegiada o confidencial. Si ha recibido este mensaje por
> error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
> proceda a su destrucción.
>
> De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
> que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
> S.A. La finalidad de dicho tratamiento es facilitar la prestación del
> servicio o información solicitados, teniendo usted derecho de acceso,
> rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
> necesaria.
>

Re: [FlexJS] Some things still missing ni FlexJS

[Alex Harui]

If someone has time, add some of these to JIRA.

Which, if any, do folks think are 1.0 requirements?  IMO, except for more
doc and tutorials, the rest of the list is optional for 1.0, but
volunteers are welcome to start now.  Other opinions welcome.

Some comments in-line...

On 1/7/17, 9:39 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala"
 wrote:

>On Sat, Jan 7, 2017 at 9:42 AM, OmPrakash Muppirala 
>wrote:
>
>>
>>
>> On Jan 7, 2017 7:59 AM, "Carlos Rovira"  wrote:
>>
>> Hi,
>>
>> I want to list some things I miss from old Flex SDK in FlexJS. Hope
>>others
>> could bring more if they want. Hope this thread could help us to know
>>what
>> people things about it, if someone expect to implement it:
>>
>> * Modules (or how to make FlexJS load discrete parts and not the all the
>> App at once. For example, in MDL I'd like to load the different panel
>> examples as I click on tabs on demand...)

IMO, this has two halves:  non-unloadable modules is relatively straight
forward to do.  Unloadable modules will be a ton of work.  IIRC, Flex 1.0
and I think even Flex 2.x grew its customer base without unloadable
modules.

>>
>> * Forms and Validation (currently there's a js:Form prepared for the
>> minimum requirements for HTML but not for SWF)

There is a VerticalColumnLayout that attempts to do some of what I think
Flex Form did.  I didn't want to call it Form since that is a known HTML
construct.

>>
>> * AMF / RemoteObject
>>
>>
>>
>>
>> * Unit testing framework (karma, jasmine)

I think Greg Dove wanted to use FlexUnit for unit testing.  What do folks
think of that idea?  We have metadata and reflection so we could do some
things that maybe the known JS frameworks can't.  But no objections to
using JS frameworks directly although not sure how to make them work in
SWF mode.

>>
>> * More charts (highcharts integration would be great)
>>
>> * Yeoman integration (yo flexjs basic | mdl)
>>
>> * i18n, i10n

My early thoughts was to leverage ValuesManager for this, but that may
turn out not to be right.

>>
>> * server side rendering  (phantomjs)
>>
>> * Automated functuonal testing (selenium,  riatest, etc)

Mustella uses Selenium for the JS side.  Run checkintests to see it.  It
is just early code and needs more work.  Volunteers are welcome.


>>
>>
>* Documentation
>* Tutorials
>* Tour De FlexJS

Thanks,
-Alex

Re: [FlexJS] Some things still missing ni FlexJS

[OmPrakash Muppirala]

On Sat, Jan 7, 2017 at 9:42 AM, OmPrakash Muppirala 
wrote:

>
>
> On Jan 7, 2017 7:59 AM, "Carlos Rovira"  wrote:
>
> Hi,
>
> I want to list some things I miss from old Flex SDK in FlexJS. Hope others
> could bring more if they want. Hope this thread could help us to know what
> people things about it, if someone expect to implement it:
>
> * Modules (or how to make FlexJS load discrete parts and not the all the
> App at once. For example, in MDL I'd like to load the different panel
> examples as I click on tabs on demand...)
>
> * Forms and Validation (currently there's a js:Form prepared for the
> minimum requirements for HTML but not for SWF)
>
> * AMF / RemoteObject
>
>
>
>
> * Unit testing framework (karma, jasmine)
>
> * More charts (highcharts integration would be great)
>
> * Yeoman integration (yo flexjs basic | mdl)
>
> * i18n, i10n
>
> * server side rendering  (phantomjs)
>
> * Automated functuonal testing (selenium,  riatest, etc)
>
>
* Documentation
* Tutorials
* Tour De FlexJS


>
> more? ...
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
>

Re: [FlexJS] Some things still missing ni FlexJS

[Carlos Rovira]

Hi Om,

about Yeoman, I didn't know about that, but it seems to me the same as a
Maven Arquetype to generate a project scaffold.
Right? If is this, we have already 3 of them (created by Chris, and we
could make more)

2017-01-07 18:42 GMT+01:00 OmPrakash Muppirala :

> On Jan 7, 2017 7:59 AM, "Carlos Rovira"  wrote:
>
> Hi,
>
> I want to list some things I miss from old Flex SDK in FlexJS. Hope others
> could bring more if they want. Hope this thread could help us to know what
> people things about it, if someone expect to implement it:
>
> * Modules (or how to make FlexJS load discrete parts and not the all the
> App at once. For example, in MDL I'd like to load the different panel
> examples as I click on tabs on demand...)
>
> * Forms and Validation (currently there's a js:Form prepared for the
> minimum requirements for HTML but not for SWF)
>
> * AMF / RemoteObject
>
>
>
>
> * Unit testing framework (karma, jasmine)
>
> * More charts (highcharts integration would be great)
>
> * Yeoman integration (yo flexjs basic | mdl)
>
> * i18n, i10n
>
> * server side rendering  (phantomjs)
>
> * Automated functuonal testing (selenium,  riatest, etc)
>
>
> more? ...
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS] Some things still missing ni FlexJS

[OmPrakash Muppirala]

On Jan 7, 2017 7:59 AM, "Carlos Rovira"  wrote:

Hi,

I want to list some things I miss from old Flex SDK in FlexJS. Hope others
could bring more if they want. Hope this thread could help us to know what
people things about it, if someone expect to implement it:

* Modules (or how to make FlexJS load discrete parts and not the all the
App at once. For example, in MDL I'd like to load the different panel
examples as I click on tabs on demand...)

* Forms and Validation (currently there's a js:Form prepared for the
minimum requirements for HTML but not for SWF)

* AMF / RemoteObject




* Unit testing framework (karma, jasmine)

* More charts (highcharts integration would be great)

* Yeoman integration (yo flexjs basic | mdl)

* i18n, i10n

* server side rendering  (phantomjs)

* Automated functuonal testing (selenium,  riatest, etc)


more? ...

--
Carlos Rovira
http://about.me/carlosrovira