Re: [FlexJS] Some things still missing ni FlexJS
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
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" 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
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
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
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
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" 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
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
+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
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
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
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
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
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
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
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
2017-01-13 20:01 GMT+01:00 Alex Harui : > > > why can't we call that our 1.0? What would be wrong with > calling that 1.0? > > As I said, for me 0.8, 1.0, 0.15 or 2.1 is not a problem. Things out there taught us that number version not really matters I'm more with the internal thinking that make us think "we're not ready yet for prime time", and my position is that we should try to cover the few holes we have as soon as we can (i.e: for me, IMHO, modules and AMF), and then as you said let people come and help we others (i.e: for example WS/WSDL, and others that seems less crucial or adopted out there). just my 2cnts -- Carlos Rovira http://about.me/carlosrovira
Re: [FlexJS] Some things still missing ni FlexJS
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
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
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
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
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
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
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
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 >>Developer Productivity. A feature fight will be very difficult for >>us to >>win without more contributors. Any feature we can produce
Re: [FlexJS] Some things still missing ni FlexJS
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 skinning support all the > Components > >> have to be completely rewritten.
Re: [FlexJS] Some things still missing ni FlexJS
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
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 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. >>
Re: [FlexJS] Some things still missing ni FlexJS
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 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
Re: [FlexJS] Some things still missing ni FlexJS
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 code that loads the module and the code in the module. Flash >will tell you right when the module loads that it
Re: [FlexJS] Some things still missing ni FlexJS
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
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
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 : > 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
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
Personally I really believe that I get a full time job where the task will be move from Flex to FlexJS. As long as I have such faith I will be contributing. It is all about attracting by this framework not only developers, but rather managers, PMs who decide abot technology in the company. In my opinion the things which we are missing is documentation, good looking controls and easy possibility to change UI. - The rest of things can come along with fully time of development. 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-tp57985p58190.html Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Some things still missing ni FlexJS
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
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 : > 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 > > 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" > > > > 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 >
Re: [FlexJS] Some things still missing ni FlexJS
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
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
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 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 > 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" > > 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 sin
Re: [FlexJS] Some things still missing ni FlexJS
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
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
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 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
Re: [FlexJS] Some things still missing ni FlexJS
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 >> >> >> 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 >>
Re: [FlexJS] Some things still missing ni FlexJS
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 >> > extensive use of CSS would make skinning easier. >> > >> > On Jan 8, 2017, at 10:49 AM, Christofer Dutz <
Re: [FlexJS] Some things still missing ni FlexJS
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 : 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
RE: [FlexJS] Some things still missing ni FlexJS
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 : > >> 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 >>>>&g
Re: [FlexJS] Some things still missing ni FlexJS
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 >>> 2017-01-08 9:52 GMT+01:00 Harbs < >>> harbs.li...@gmail.com>: >>>> I agree that skinning is harder than it should b
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 : 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 documentación necesaria.
Re: [FlexJS] Some things still missing ni FlexJS
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 facilitar la > >>prestación > >> del > >> >> servicio o información solicitados, teniendo usted derecho de > >> acceso, > >>
Re: [FlexJS] Some things still missing ni FlexJS
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
+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
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
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
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
+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
"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
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.
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 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
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
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
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
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
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
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