Re: New Flex to JS project
Ah ok. I wasn't aware that the custom UI components was a separate piece. Thanks, -Alex On 7/9/14 11:20 PM, "Harbs" wrote: >Angular does not provide the "lego". Rather, it describes how the pieces >are supposed to connect and how the pieces should be constructed. > >Angular is all about connecting the html markup with javascript. > >Angular introduces custom html attributes (the default ones are prefixed >ng but custom ones can be created as well) which the framework wires >together (2-way binding) with the model (ng-model) described in the >$scope of that element. Angular has a elaborate inheritance hierarchy of >html elements where html elements ³inherit² the $scope of its parent >element unless it uses a different ng-model. > >All the built-in Angular attributes are *behaviors* rather than >*components*. You could probably put those in two categories: >1. Those which extend default HTML behavior (i.e. ng-show, ng-mousedown, >ng-src, etc.) >2. "functional" attributes like ng-repeat, ng-switch on, etc. > >The first category binds javascript objects and properties with html >elements, while the second category actually changes the html structure. > >Of course custom components can be (and should be) created and that¹s >what AngularUI[1] is all about, but it¹s not part of the core framework. > >Does this make more sense? > >HTH, >Harbs > >[1] http://angular-ui.github.io/ >On Jul 10, 2014, at 8:57 AM, Alex Harui wrote: > >> I'm still trying to understand why you don't think there is "lego" in >> Angular. >
Re: New Flex to JS project
Angular does not provide the "lego". Rather, it describes how the pieces are supposed to connect and how the pieces should be constructed. Angular is all about connecting the html markup with javascript. Angular introduces custom html attributes (the default ones are prefixed ng but custom ones can be created as well) which the framework wires together (2-way binding) with the model (ng-model) described in the $scope of that element. Angular has a elaborate inheritance hierarchy of html elements where html elements “inherit” the $scope of its parent element unless it uses a different ng-model. All the built-in Angular attributes are *behaviors* rather than *components*. You could probably put those in two categories: 1. Those which extend default HTML behavior (i.e. ng-show, ng-mousedown, ng-src, etc.) 2. "functional" attributes like ng-repeat, ng-switch on, etc. The first category binds javascript objects and properties with html elements, while the second category actually changes the html structure. Of course custom components can be (and should be) created and that’s what AngularUI[1] is all about, but it’s not part of the core framework. Does this make more sense? HTH, Harbs [1] http://angular-ui.github.io/ On Jul 10, 2014, at 8:57 AM, Alex Harui wrote: > I'm still trying to understand why you don't think there is "lego" in > Angular.
Re: New Flex to JS project
On 7/9/14 3:32 PM, "Harbs" wrote: >It seems to me there¹s a question of perception as to what ³Flex² is. > >Historically, Flex has been an application framework centered around >components. The equivalent in the JS world would probably be something >like Sencha¹s UI frameworks. (i.e. ext js) or JQuery UI. So, when people >hear ³Flex² they think ³application lego². > >Flex also has the functionality of the class of frameworks (in the js >world) like Ember or Angular which deal mostly with data consumption and >data binding. Very little lego there. It¹s more the glue that holds stuff >together. > >We also have the Falcon compiler which enables cross-compiling >ActionScript irrespective of the application components (ala ext js) or >the application ³glue² ala Angular. > >It seems to me that to call all of these things ³FlexJS² seems too broad >to prevent confusion. It seems to me that there needs to be a distinction >between these different areas of capabilities. > >Thoughts? Awesome. I liked your breakdown of the pieces. I'm definitely open to ideas around naming. Hopefully others will offer ideas as well. I'm still trying to understand why you don't think there is "lego" in Angular. I'm not saying you're wrong because all I've really done is read some of the web-site stuff. The web-site at [1] looks like it is introducing custom HTML UI tags. I thought that was also part of the reason for its name (the angle brackets in HTML). [1] https://angularjs.org -Alex
Re: New Flex to JS project
It seems to me there’s a question of perception as to what “Flex” is. Historically, Flex has been an application framework centered around components. The equivalent in the JS world would probably be something like Sencha’s UI frameworks. (i.e. ext js) or JQuery UI. So, when people hear “Flex” they think “application lego”. Flex also has the functionality of the class of frameworks (in the js world) like Ember or Angular which deal mostly with data consumption and data binding. Very little lego there. It’s more the glue that holds stuff together. We also have the Falcon compiler which enables cross-compiling ActionScript irrespective of the application components (ala ext js) or the application “glue” ala Angular. It seems to me that to call all of these things “FlexJS” seems too broad to prevent confusion. It seems to me that there needs to be a distinction between these different areas of capabilities. Thoughts? On Jul 10, 2014, at 12:43 AM, Alex Harui wrote: > Well, like I said, I'm not an expert on this stuff. My brief look at > Angular gave me the impression that it was about declarative markup for an > extensible component model. I think that's what we have too. > > The key point that I'm not sure is sticking with folks is that FlexJS may > have a default framework, but I really want it to be framework-agnostic. > A framework developer can implement, mimic or mock the JS components from > some JS framework in an AS SWC to enable the application developer to glue > their favorite JS components together with AS. Then the final > cross-compiled output has a much better chance of working correctly, and > the net should be better developer productivity. > > -Alex > > On 7/9/14 11:13 AM, "Harbs" wrote: > >> Hmm. >> >> I might have been misunderstanding you. >> >> I thought you were discussing getting FlexJS with mxml markup, data >> binding and everything else to work with Angular. That’s what I don’t see >> as a fit. >> >> If you mean to simply write Angular applications in AS instead of JS and >> cross-compile using FalconJX, then yes, that should (probably) work. >> Besides TypeScript, you can also use CoffeeScript as well as Angular Dart. >> >> I can see an argument to write Angular in AS, but that is just utilizing >> the compiler, rather than the FlexJS framework as a whole. I also don’t >> think that it makes sense to create an ActionScript compile target for >> Angular apps. >> >> Harbs >> >> On Jul 9, 2014, at 8:48 PM, Alex Harui wrote: >> >>> OK, I'll try to find time to read up on Angular. It does appear that >>> TypeScript works with Angular. My rudimentary understanding of this >>> stuff >>> says that if you can use TS you should be able to use AS as well, but I >>> could certainly be wrong. >>> >>> -Alex >>> >>> On 7/9/14 10:43 AM, "Harbs" wrote: >>> FWIW, here’s some Angular-compatible components: http://angular-ui.github.io/ http://angular-ui.github.io/bootstrap/ http://angular-ui.github.io/ng-grid/ and a whole site dedicated to cataloging Angular modules (some of it UI, and some of it business logic): http://ngmodules.org/ As you can see, except for the basic HTML elements, any UI that is used with Angular is going to be external modules from either existing UI frameworks (i.e. Bootstrap), or ones built specifically for Angular. None of these are part of the core Angular framework. I do think that for FlexJS to be successful, we would need some kind of public catalog of external modules (components) similar to the ngmodules site. On Jul 9, 2014, at 8:11 PM, Harbs wrote: > Angular is not really components. It’s more the glue that holds the > components together. > > Basically, the selling point of Angular is how it binds javascript to > HTML. Building custom Angular components is the hardest part of using > the framework (and for the most part is not part of the framework > itself). They call them “directives” and they have very unintuitive > json > markup that goes with the js code. > > Angular pretty strongly prescribes how the app is put together and > it’s > comprised of HTML template and directive files which comprise the > view, > and controller/factory/service files which comprise the model and > controller. > > > On Jul 9, 2014, at 7:44 PM, Alex Harui wrote: > >> >> >> On 7/9/14 9:16 AM, "Harbs" wrote: >> >>> I wouldn¹t call myself an expert on the subject, but I have had the >>> opportunity to familiarize myself with both Angular and Create.js >>> the >>> past half year. >>> >>> Create.js makes sense to integrate into FlexJS. I¹m not sure I >>> understand >>> how Angular would/could be integrated. It seems to me that Angular >>> is >>> a >>> competing framework and I don¹t und
Re: New Flex to JS project
Well, like I said, I'm not an expert on this stuff. My brief look at Angular gave me the impression that it was about declarative markup for an extensible component model. I think that's what we have too. The key point that I'm not sure is sticking with folks is that FlexJS may have a default framework, but I really want it to be framework-agnostic. A framework developer can implement, mimic or mock the JS components from some JS framework in an AS SWC to enable the application developer to glue their favorite JS components together with AS. Then the final cross-compiled output has a much better chance of working correctly, and the net should be better developer productivity. -Alex On 7/9/14 11:13 AM, "Harbs" wrote: >Hmm. > >I might have been misunderstanding you. > >I thought you were discussing getting FlexJS with mxml markup, data >binding and everything else to work with Angular. That’s what I don’t see >as a fit. > >If you mean to simply write Angular applications in AS instead of JS and >cross-compile using FalconJX, then yes, that should (probably) work. >Besides TypeScript, you can also use CoffeeScript as well as Angular Dart. > >I can see an argument to write Angular in AS, but that is just utilizing >the compiler, rather than the FlexJS framework as a whole. I also don’t >think that it makes sense to create an ActionScript compile target for >Angular apps. > >Harbs > >On Jul 9, 2014, at 8:48 PM, Alex Harui wrote: > >> OK, I'll try to find time to read up on Angular. It does appear that >> TypeScript works with Angular. My rudimentary understanding of this >>stuff >> says that if you can use TS you should be able to use AS as well, but I >> could certainly be wrong. >> >> -Alex >> >> On 7/9/14 10:43 AM, "Harbs" wrote: >> >>> FWIW, here’s some Angular-compatible components: >>> http://angular-ui.github.io/ >>> http://angular-ui.github.io/bootstrap/ >>> http://angular-ui.github.io/ng-grid/ >>> >>> and a whole site dedicated to cataloging Angular modules (some of it >>>UI, >>> and some of it business logic): >>> http://ngmodules.org/ >>> >>> As you can see, except for the basic HTML elements, any UI that is used >>> with Angular is going to be external modules from either existing UI >>> frameworks (i.e. Bootstrap), or ones built specifically for Angular. >>>None >>> of these are part of the core Angular framework. >>> >>> I do think that for FlexJS to be successful, we would need some kind of >>> public catalog of external modules (components) similar to the >>>ngmodules >>> site. >>> >>> On Jul 9, 2014, at 8:11 PM, Harbs wrote: >>> Angular is not really components. It’s more the glue that holds the components together. Basically, the selling point of Angular is how it binds javascript to HTML. Building custom Angular components is the hardest part of using the framework (and for the most part is not part of the framework itself). They call them “directives” and they have very unintuitive json markup that goes with the js code. Angular pretty strongly prescribes how the app is put together and it’s comprised of HTML template and directive files which comprise the view, and controller/factory/service files which comprise the model and controller. On Jul 9, 2014, at 7:44 PM, Alex Harui wrote: > > > On 7/9/14 9:16 AM, "Harbs" wrote: > >> I wouldn¹t call myself an expert on the subject, but I have had the >> opportunity to familiarize myself with both Angular and Create.js >>the >> past half year. >> >> Create.js makes sense to integrate into FlexJS. I¹m not sure I >> understand >> how Angular would/could be integrated. It seems to me that Angular >>is >> a >> competing framework and I don¹t understand how the two could work >> together. > IMO, most JS frameworks offer a set of components that you glue > together > with JS. I'm not an expert on these frameworks, but I think Angular >is > one of them. Assuming the JS framework is not buggy, I think there >is > a > lot of pain in writing and debugging the JS code that glues the > components > together (the rest of the pain is probably in browser-specific >issues). > TypeScript seems to have reached the same conclusion and offers a new > language to do the gluing. I'd say Dart and GWT also have the same > thoughts. > > FlexJS has the potential to be on-par or better as a way to do the > gluing. > We have IDEs, we have runtime verification, and we have declarative > markup in MXML. > > Think of it this way. If IKEA or other assemble-it-yourself >furniture > makers shipped you a box of pieces cut to size and then just nails >and > screws and pre-drilled holes, you'd make a lot of mistakes building >the > furniture. Instead, these manufacturers use special
Re: New Flex to JS project
Hmm. I might have been misunderstanding you. I thought you were discussing getting FlexJS with mxml markup, data binding and everything else to work with Angular. That’s what I don’t see as a fit. If you mean to simply write Angular applications in AS instead of JS and cross-compile using FalconJX, then yes, that should (probably) work. Besides TypeScript, you can also use CoffeeScript as well as Angular Dart. I can see an argument to write Angular in AS, but that is just utilizing the compiler, rather than the FlexJS framework as a whole. I also don’t think that it makes sense to create an ActionScript compile target for Angular apps. Harbs On Jul 9, 2014, at 8:48 PM, Alex Harui wrote: > OK, I'll try to find time to read up on Angular. It does appear that > TypeScript works with Angular. My rudimentary understanding of this stuff > says that if you can use TS you should be able to use AS as well, but I > could certainly be wrong. > > -Alex > > On 7/9/14 10:43 AM, "Harbs" wrote: > >> FWIW, here’s some Angular-compatible components: >> http://angular-ui.github.io/ >> http://angular-ui.github.io/bootstrap/ >> http://angular-ui.github.io/ng-grid/ >> >> and a whole site dedicated to cataloging Angular modules (some of it UI, >> and some of it business logic): >> http://ngmodules.org/ >> >> As you can see, except for the basic HTML elements, any UI that is used >> with Angular is going to be external modules from either existing UI >> frameworks (i.e. Bootstrap), or ones built specifically for Angular. None >> of these are part of the core Angular framework. >> >> I do think that for FlexJS to be successful, we would need some kind of >> public catalog of external modules (components) similar to the ngmodules >> site. >> >> On Jul 9, 2014, at 8:11 PM, Harbs wrote: >> >>> Angular is not really components. It’s more the glue that holds the >>> components together. >>> >>> Basically, the selling point of Angular is how it binds javascript to >>> HTML. Building custom Angular components is the hardest part of using >>> the framework (and for the most part is not part of the framework >>> itself). They call them “directives” and they have very unintuitive json >>> markup that goes with the js code. >>> >>> Angular pretty strongly prescribes how the app is put together and it’s >>> comprised of HTML template and directive files which comprise the view, >>> and controller/factory/service files which comprise the model and >>> controller. >>> >>> >>> On Jul 9, 2014, at 7:44 PM, Alex Harui wrote: >>> On 7/9/14 9:16 AM, "Harbs" wrote: > I wouldn¹t call myself an expert on the subject, but I have had the > opportunity to familiarize myself with both Angular and Create.js the > past half year. > > Create.js makes sense to integrate into FlexJS. I¹m not sure I > understand > how Angular would/could be integrated. It seems to me that Angular is > a > competing framework and I don¹t understand how the two could work > together. IMO, most JS frameworks offer a set of components that you glue together with JS. I'm not an expert on these frameworks, but I think Angular is one of them. Assuming the JS framework is not buggy, I think there is a lot of pain in writing and debugging the JS code that glues the components together (the rest of the pain is probably in browser-specific issues). TypeScript seems to have reached the same conclusion and offers a new language to do the gluing. I'd say Dart and GWT also have the same thoughts. FlexJS has the potential to be on-par or better as a way to do the gluing. We have IDEs, we have runtime verification, and we have declarative markup in MXML. Think of it this way. If IKEA or other assemble-it-yourself furniture makers shipped you a box of pieces cut to size and then just nails and screws and pre-drilled holes, you'd make a lot of mistakes building the furniture. Instead, these manufacturers use special connectors making it much more clear what goes where and making it impossible to make certain kinds of errors. IMO, classes are those special connectors. JS is just nails and screws. In JS, you can attach anything to anything and won't find out until much later. In FlexJS, we can offer both better connectors and a schematic diagram (MXML). -Alex > > On Jul 9, 2014, at 5:28 PM, Alex Harui wrote: > >> I hope to attract Jquery, Angular, >> CreateJS experts and fans to build out these frameworks and making >> them >> wade through the current SDK would probably be an inhibitor to them. > >>> >> >
Re: New Flex to JS project
OK, I'll try to find time to read up on Angular. It does appear that TypeScript works with Angular. My rudimentary understanding of this stuff says that if you can use TS you should be able to use AS as well, but I could certainly be wrong. -Alex On 7/9/14 10:43 AM, "Harbs" wrote: >FWIW, here’s some Angular-compatible components: >http://angular-ui.github.io/ >http://angular-ui.github.io/bootstrap/ >http://angular-ui.github.io/ng-grid/ > >and a whole site dedicated to cataloging Angular modules (some of it UI, >and some of it business logic): >http://ngmodules.org/ > >As you can see, except for the basic HTML elements, any UI that is used >with Angular is going to be external modules from either existing UI >frameworks (i.e. Bootstrap), or ones built specifically for Angular. None >of these are part of the core Angular framework. > >I do think that for FlexJS to be successful, we would need some kind of >public catalog of external modules (components) similar to the ngmodules >site. > >On Jul 9, 2014, at 8:11 PM, Harbs wrote: > >> Angular is not really components. It’s more the glue that holds the >>components together. >> >> Basically, the selling point of Angular is how it binds javascript to >>HTML. Building custom Angular components is the hardest part of using >>the framework (and for the most part is not part of the framework >>itself). They call them “directives” and they have very unintuitive json >>markup that goes with the js code. >> >> Angular pretty strongly prescribes how the app is put together and it’s >>comprised of HTML template and directive files which comprise the view, >>and controller/factory/service files which comprise the model and >>controller. >> >> >> On Jul 9, 2014, at 7:44 PM, Alex Harui wrote: >> >>> >>> >>> On 7/9/14 9:16 AM, "Harbs" wrote: >>> I wouldn¹t call myself an expert on the subject, but I have had the opportunity to familiarize myself with both Angular and Create.js the past half year. Create.js makes sense to integrate into FlexJS. I¹m not sure I understand how Angular would/could be integrated. It seems to me that Angular is a competing framework and I don¹t understand how the two could work together. >>> IMO, most JS frameworks offer a set of components that you glue >>>together >>> with JS. I'm not an expert on these frameworks, but I think Angular is >>> one of them. Assuming the JS framework is not buggy, I think there is >>>a >>> lot of pain in writing and debugging the JS code that glues the >>>components >>> together (the rest of the pain is probably in browser-specific issues). >>> TypeScript seems to have reached the same conclusion and offers a new >>> language to do the gluing. I'd say Dart and GWT also have the same >>> thoughts. >>> >>> FlexJS has the potential to be on-par or better as a way to do the >>>gluing. >>> We have IDEs, we have runtime verification, and we have declarative >>> markup in MXML. >>> >>> Think of it this way. If IKEA or other assemble-it-yourself furniture >>> makers shipped you a box of pieces cut to size and then just nails and >>> screws and pre-drilled holes, you'd make a lot of mistakes building the >>> furniture. Instead, these manufacturers use special connectors making >>>it >>> much more clear what goes where and making it impossible to make >>>certain >>> kinds of errors. >>> >>> IMO, classes are those special connectors. JS is just nails and >>>screws. >>> In JS, you can attach anything to anything and won't find out until >>>much >>> later. In FlexJS, we can offer both better connectors and a schematic >>> diagram (MXML). >>> >>> -Alex >>> On Jul 9, 2014, at 5:28 PM, Alex Harui wrote: > I hope to attract Jquery, Angular, > CreateJS experts and fans to build out these frameworks and making >them > wade through the current SDK would probably be an inhibitor to them. >>> >> >
Re: New Flex to JS project
FWIW, here’s some Angular-compatible components: http://angular-ui.github.io/ http://angular-ui.github.io/bootstrap/ http://angular-ui.github.io/ng-grid/ and a whole site dedicated to cataloging Angular modules (some of it UI, and some of it business logic): http://ngmodules.org/ As you can see, except for the basic HTML elements, any UI that is used with Angular is going to be external modules from either existing UI frameworks (i.e. Bootstrap), or ones built specifically for Angular. None of these are part of the core Angular framework. I do think that for FlexJS to be successful, we would need some kind of public catalog of external modules (components) similar to the ngmodules site. On Jul 9, 2014, at 8:11 PM, Harbs wrote: > Angular is not really components. It’s more the glue that holds the > components together. > > Basically, the selling point of Angular is how it binds javascript to HTML. > Building custom Angular components is the hardest part of using the framework > (and for the most part is not part of the framework itself). They call them > “directives” and they have very unintuitive json markup that goes with the js > code. > > Angular pretty strongly prescribes how the app is put together and it’s > comprised of HTML template and directive files which comprise the view, and > controller/factory/service files which comprise the model and controller. > > > On Jul 9, 2014, at 7:44 PM, Alex Harui wrote: > >> >> >> On 7/9/14 9:16 AM, "Harbs" wrote: >> >>> I wouldn¹t call myself an expert on the subject, but I have had the >>> opportunity to familiarize myself with both Angular and Create.js the >>> past half year. >>> >>> Create.js makes sense to integrate into FlexJS. I¹m not sure I understand >>> how Angular would/could be integrated. It seems to me that Angular is a >>> competing framework and I don¹t understand how the two could work >>> together. >> IMO, most JS frameworks offer a set of components that you glue together >> with JS. I'm not an expert on these frameworks, but I think Angular is >> one of them. Assuming the JS framework is not buggy, I think there is a >> lot of pain in writing and debugging the JS code that glues the components >> together (the rest of the pain is probably in browser-specific issues). >> TypeScript seems to have reached the same conclusion and offers a new >> language to do the gluing. I'd say Dart and GWT also have the same >> thoughts. >> >> FlexJS has the potential to be on-par or better as a way to do the gluing. >> We have IDEs, we have runtime verification, and we have declarative >> markup in MXML. >> >> Think of it this way. If IKEA or other assemble-it-yourself furniture >> makers shipped you a box of pieces cut to size and then just nails and >> screws and pre-drilled holes, you'd make a lot of mistakes building the >> furniture. Instead, these manufacturers use special connectors making it >> much more clear what goes where and making it impossible to make certain >> kinds of errors. >> >> IMO, classes are those special connectors. JS is just nails and screws. >> In JS, you can attach anything to anything and won't find out until much >> later. In FlexJS, we can offer both better connectors and a schematic >> diagram (MXML). >> >> -Alex >> >>> >>> On Jul 9, 2014, at 5:28 PM, Alex Harui wrote: >>> I hope to attract Jquery, Angular, CreateJS experts and fans to build out these frameworks and making them wade through the current SDK would probably be an inhibitor to them. >>> >> >
Re: New Flex to JS project
Angular is not really components. It’s more the glue that holds the components together. Basically, the selling point of Angular is how it binds javascript to HTML. Building custom Angular components is the hardest part of using the framework (and for the most part is not part of the framework itself). They call them “directives” and they have very unintuitive json markup that goes with the js code. Angular pretty strongly prescribes how the app is put together and it’s comprised of HTML template and directive files which comprise the view, and controller/factory/service files which comprise the model and controller. On Jul 9, 2014, at 7:44 PM, Alex Harui wrote: > > > On 7/9/14 9:16 AM, "Harbs" wrote: > >> I wouldn¹t call myself an expert on the subject, but I have had the >> opportunity to familiarize myself with both Angular and Create.js the >> past half year. >> >> Create.js makes sense to integrate into FlexJS. I¹m not sure I understand >> how Angular would/could be integrated. It seems to me that Angular is a >> competing framework and I don¹t understand how the two could work >> together. > IMO, most JS frameworks offer a set of components that you glue together > with JS. I'm not an expert on these frameworks, but I think Angular is > one of them. Assuming the JS framework is not buggy, I think there is a > lot of pain in writing and debugging the JS code that glues the components > together (the rest of the pain is probably in browser-specific issues). > TypeScript seems to have reached the same conclusion and offers a new > language to do the gluing. I'd say Dart and GWT also have the same > thoughts. > > FlexJS has the potential to be on-par or better as a way to do the gluing. > We have IDEs, we have runtime verification, and we have declarative > markup in MXML. > > Think of it this way. If IKEA or other assemble-it-yourself furniture > makers shipped you a box of pieces cut to size and then just nails and > screws and pre-drilled holes, you'd make a lot of mistakes building the > furniture. Instead, these manufacturers use special connectors making it > much more clear what goes where and making it impossible to make certain > kinds of errors. > > IMO, classes are those special connectors. JS is just nails and screws. > In JS, you can attach anything to anything and won't find out until much > later. In FlexJS, we can offer both better connectors and a schematic > diagram (MXML). > > -Alex > >> >> On Jul 9, 2014, at 5:28 PM, Alex Harui wrote: >> >>> I hope to attract Jquery, Angular, >>> CreateJS experts and fans to build out these frameworks and making them >>> wade through the current SDK would probably be an inhibitor to them. >> >
Re: New Flex to JS project
On 7/9/14 9:16 AM, "Harbs" wrote: >I wouldn¹t call myself an expert on the subject, but I have had the >opportunity to familiarize myself with both Angular and Create.js the >past half year. > >Create.js makes sense to integrate into FlexJS. I¹m not sure I understand >how Angular would/could be integrated. It seems to me that Angular is a >competing framework and I don¹t understand how the two could work >together. IMO, most JS frameworks offer a set of components that you glue together with JS. I'm not an expert on these frameworks, but I think Angular is one of them. Assuming the JS framework is not buggy, I think there is a lot of pain in writing and debugging the JS code that glues the components together (the rest of the pain is probably in browser-specific issues). TypeScript seems to have reached the same conclusion and offers a new language to do the gluing. I'd say Dart and GWT also have the same thoughts. FlexJS has the potential to be on-par or better as a way to do the gluing. We have IDEs, we have runtime verification, and we have declarative markup in MXML. Think of it this way. If IKEA or other assemble-it-yourself furniture makers shipped you a box of pieces cut to size and then just nails and screws and pre-drilled holes, you'd make a lot of mistakes building the furniture. Instead, these manufacturers use special connectors making it much more clear what goes where and making it impossible to make certain kinds of errors. IMO, classes are those special connectors. JS is just nails and screws. In JS, you can attach anything to anything and won't find out until much later. In FlexJS, we can offer both better connectors and a schematic diagram (MXML). -Alex > >On Jul 9, 2014, at 5:28 PM, Alex Harui wrote: > >> I hope to attract Jquery, Angular, >> CreateJS experts and fans to build out these frameworks and making them >> wade through the current SDK would probably be an inhibitor to them. >
Re: New Flex to JS project
I wouldn’t call myself an expert on the subject, but I have had the opportunity to familiarize myself with both Angular and Create.js the past half year. Create.js makes sense to integrate into FlexJS. I’m not sure I understand how Angular would/could be integrated. It seems to me that Angular is a competing framework and I don’t understand how the two could work together. On Jul 9, 2014, at 5:28 PM, Alex Harui wrote: > I hope to attract Jquery, Angular, > CreateJS experts and fans to build out these frameworks and making them > wade through the current SDK would probably be an inhibitor to them.
Re: New Flex to JS project
On 7/9/14 2:04 AM, "Erik de Bruin" wrote: >Alex, > >Wow! Awesome email, if nothing else then only by weight of the bytes ;-) I'll try to make this one shorter. > >I'm not sure you entirely get what I'm trying to do, but keeping an open >mind I'm looking for ways to combine the two approaches. You seem to be >suggesting that VF2JS can exist as an option in FlexJS. We need to explore >that idea to see if we might be able to make it work. > >1) Currently, FlexJS has it's own AS framework, without any of the >Spark/MX >components. VF2JS needs those; remember, VF2JS let's users develop their >SWF apps in the classic SDK, like they are used to. Do you suggest we >merge >FlexJS into the current SDK? Again, FlexJS hopes to support multiple AS frameworks. Eventually we'll carve the Jquery, Cordova, and CreateJS stuff out of the current "basic" SWC and JS folders into their own SWCs and JS folders. There will be separate SWCs and JS folders for Angular and whatever JS frameworks folks want to wrap. The compiler/namespace stuff should support this already, just like folks can use non-Flex SWCs in AS-only projects. I don't think we need to merge these SWC/folder sets into the main SDK as they don't have any reliance on the SDK code and will simplify development and releasing by maintaining separation. But VJS can be packaged in whatever way makes sense. FlexJS installs already pull in MXMLC jars from the current SDK, the VJS SWCs can certainly rely on current Flex SDK SWCs. All of the FlexJS SWCs rely on playerglobal.swc. All that should matter is what SWCs are listed in the config at compile time. > >2) The FlexJS JS implementation uses data arrays to represent MXML. This >means that class member names are stored as strings. The GCC can't rename >strings. In order to match the strings to the actual properties, the >properties cannot be renamed either - you can't match 'myComponent.width' >to 'a.b' ;-) This is why all public properties have the @expose >annotation. >But here is the kicker: using @expose prevents the GCC from doing a >significant amount of optimisations. In VF2JS I'm planning on doing away >with the data arrays so we get to use the full force of GCC optimisation >and minification, and can do away with the client side dynamic object >creation from the array. The data array output is just a flag in Falcon (compiler.mxml.children-as-data). If you want it to be off for VJS compiles that's fine. There's probably some tweaks needed when you turn that off. One of the reasons I set up MXML as data is that several folks have asked to be able to modify the MXML output and the data array was the only way I could think of to do that without sacrificing performance. I'm open to other options. Folks may ask that of VJS MXML compilation as well. > >3) I'm liking the idea of having FalconJX detect the namespaces it is fed >and use that information to decide the compile path. That way if it reads >Spark/MX, it would use the VF2JS JS framework, if it reads Basic/Core, if >would go the FlexJS route. I was thinking it might be not too hard to add -namespace-override=$. I still want to do it in Falcon so you find out early instead of at cross-compile time. I think we probably need a package/import override too for AS code. > >4) The organisation of the JS frameworks would need some rethinking. >FlexJS >also uses the 'flash.display' and 'mx.core'/'mx.states' namespaces. We >don't want collisions there. Oh yes. A good name scrub and folder re-org is definitely needed. I'm not good at it and hope someone who is will step up. > >5) The reason I'm hiding the AS SWC because I don't want to bother the >user >with having to use different xmlns. It would be sweet though to have >Falcon >do the switching on the fly, so we get compiler feedback about portability >during development, e.g. using a compiler argument indicating you want to >also be able to cross compile your code to JS. That way the shim SWCs >could >still be that, shims, but I like the idea of adding metadata to indicate >JS >(un)availability. Yeah, either metadata and/or some other data file to inform the compiler. We probably can't modify playerglobal.swc so we might need an external file for that. Or we could shim playerglobal... > >6) We need to rethink the naming convention. I like FlexJS, it should stay >for the name of the AS to JS project. But the various frameworks need >different names. On the AS side, after we 'merge', I guess there are 4: >Flex (the regular SDK, used by the VF2JS approach), FlexJSUI, FlexJS and >MXMLCClasses. On the JS side, there would be lots and lots, some of them >(possibly) colliding: see point 4). What is your view on the organisation >of these various aspects, especially given that (see point 1) we might >merge FlexJS into the regular SDK? Definitely open to ideas on renaming and reorganizing. IMO, the SWCs and JS folders that don't have a reliance on the current SDK should probably not be merged into the c
Re: New Flex to JS project
On 09/07/14 06:56, Alex Harui wrote: > At one point I was told that battery > life was going to limit device cpu performance growth rates. Medium. We're already seeing signs of people getting of the upgrade treadmill, and moving to SIM-only deals because their current device is 'good enough'. Manufacturers are noticing, and adding stuff like waterproofing. I'm hopeful they'll give up on 'who's thinner' and instead become a bit thicker and be all battery :-) Tom
Re: New Flex to JS project
Alex, Wow! Awesome email, if nothing else then only by weight of the bytes ;-) I'm not sure you entirely get what I'm trying to do, but keeping an open mind I'm looking for ways to combine the two approaches. You seem to be suggesting that VF2JS can exist as an option in FlexJS. We need to explore that idea to see if we might be able to make it work. 1) Currently, FlexJS has it's own AS framework, without any of the Spark/MX components. VF2JS needs those; remember, VF2JS let's users develop their SWF apps in the classic SDK, like they are used to. Do you suggest we merge FlexJS into the current SDK? 2) The FlexJS JS implementation uses data arrays to represent MXML. This means that class member names are stored as strings. The GCC can't rename strings. In order to match the strings to the actual properties, the properties cannot be renamed either - you can't match 'myComponent.width' to 'a.b' ;-) This is why all public properties have the @expose annotation. But here is the kicker: using @expose prevents the GCC from doing a significant amount of optimisations. In VF2JS I'm planning on doing away with the data arrays so we get to use the full force of GCC optimisation and minification, and can do away with the client side dynamic object creation from the array. 3) I'm liking the idea of having FalconJX detect the namespaces it is fed and use that information to decide the compile path. That way if it reads Spark/MX, it would use the VF2JS JS framework, if it reads Basic/Core, if would go the FlexJS route. 4) The organisation of the JS frameworks would need some rethinking. FlexJS also uses the 'flash.display' and 'mx.core'/'mx.states' namespaces. We don't want collisions there. 5) The reason I'm hiding the AS SWC because I don't want to bother the user with having to use different xmlns. It would be sweet though to have Falcon do the switching on the fly, so we get compiler feedback about portability during development, e.g. using a compiler argument indicating you want to also be able to cross compile your code to JS. That way the shim SWCs could still be that, shims, but I like the idea of adding metadata to indicate JS (un)availability. 6) We need to rethink the naming convention. I like FlexJS, it should stay for the name of the AS to JS project. But the various frameworks need different names. On the AS side, after we 'merge', I guess there are 4: Flex (the regular SDK, used by the VF2JS approach), FlexJSUI, FlexJS and MXMLCClasses. On the JS side, there would be lots and lots, some of them (possibly) colliding: see point 4). What is your view on the organisation of these various aspects, especially given that (see point 1) we might merge FlexJS into the regular SDK? That should be enough food for thought ;-) Let's see if we can make this work! EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: New Flex to JS project
On 7/8/14 11:22 AM, "DarkStone" wrote: >My point is, the mobile applications made with the current Flex SDK are >running very smooth in modern cheap mobile devices, and they will be >running even smoother in every 3 months. Hi Darkstone, Thanks for that info. At one point I was told that battery life was going to limit device cpu performance growth rates. Is that no longer the case? > > >So I believe the performance issue of Flex is not our primary concerns, >no need to re-design the FlexJS architecture from the ground up, just >base on the current Spark architecture and make improvements, that's fair >enough in my opinion. It is nice to know that more apps have a chance to work running on JS emulations of Flash-isms like e4x, weak references and xml notifications, but are you sure "all" apps will? At one point in Flex's history, lots of apps worked as long as you had recent desktop hardware and a fast intranet. Then apps got bigger, folks tried to deploy those bigger apps on slower networks, and then a new wave of mobile devices came out that had performance constraints and Flex lost momentum. Could that happen again? Could there be some other frontier of new technology that will run JS in a constrained environment? I've already spent a lot of time trying to improve the current SDK. I've given up and am starting over, designing it for what we want it to do, instead of trying to emulate things we wish the JS platform had, because, at the end of the day, if you are running on top of emulations, folks can still point fingers at it and say that is isn't as good as "native". Every time there is additional CPU capability, eventually the OS and other apps starting eating away at it. We would never have deployed auto-updaters 10 years ago, but guess how many are now running on my Mac? More and more people have faster networks, but will your app be the one that works when the network is busy with other traffic? One of the reasons I "gave up" is because the SDK is very fragile and full of interconnected class dependencies. It is hard to separate things into smaller chunks. Folks have mentioned that as an inhibitor to contributing to the project. The components I'm working on and their beads are intended to make contributing easier. By having good separation, you can hopefully put together another bead and contribute it without fear of breaking something else. Yes, there will be a lot of beads but I'm hopeful that tools and documentation will help you manage. If folks can manage choosing things in a WalMart, hopefully they can choose beads. It will be interesting to see how Erik codes up the JS side. I would build it out of JS beads so there is that separation. But doing it for all of current Flex sounds like a considerable task. You can probably make good progress in the early going, but as you get closer to emulating all of current Flex you have to start reproducing those awful interconnected class dependencies and things may become fragile again (or fat and slow) But there's no way to know for sure until folks dive in. In my presentations I talk about doing an "80% Spark" component set that never does "everything" the current SDK can do. It simply doesn't implement the hard stuff, but that means that folks have to do more work during migration. Anyway, I don't think we have to decide on one approach now. I don't think anything Erik said weakens the potential of FlexJS. I still hope to convince him he is simply implementing one of many component sets. I think it will be good to offer folks different trade-offs on how much migration work vs options on using different JS frameworks under the covers or having a lighter weight JS download. But I do hope folks jump in an help on either effort. My biggest fear is that folks will sit on the sidelines hoping that someone can in fact produce the zero-migration JS framework that has little additional overhead. We've got a lot of work ahead of us, no matter what. > >I do agree the current Flex SDK is fat and old. >For fat: I think we should get rid of the halo (mx) legacy stuff, and >continue improving the Spark architecture to lose weight and gain >performance. That probably won't help Spark. It lives on top of a lot of mx stuff. >For old: I think we should focus more on the mobile supports of Spark >framework, like adding more mobile components and skin themes (I know Om >is working on one). Any one interested in doing so is welcome to do so. That's the Apache Way. For now, I'll still be plugging away at making Flex the fastest way to create JS apps on any JS framework. -Alex
Re:Re: New Flex to JS project
Hi Alex, One very important thing I have to point out: The hardware of the mobile devices are improving rapidly, way faster than the way of the desktop devices do. In China, there are already millions of Android phones with 2GB RAM + 4 Core CPU, under the price of $100, and I just bought a 2GB RAM + 8 Core CPU + 5 inches screen of Android phone for my mom last month, cost me ￥680 ($108). Chinese mobile hardware companies are rising, the price war is reaching its climax. My point is, the mobile applications made with the current Flex SDK are running very smooth in modern cheap mobile devices, and they will be running even smoother in every 3 months. So I believe the performance issue of Flex is not our primary concerns, no need to re-design the FlexJS architecture from the ground up, just base on the current Spark architecture and make improvements, that's fair enough in my opinion. I do agree the current Flex SDK is fat and old. For fat: I think we should get rid of the halo (mx) legacy stuff, and continue improving the Spark architecture to lose weight and gain performance. For old: I think we should focus more on the mobile supports of Spark framework, like adding more mobile components and skin themes (I know Om is working on one). DarkStone 2014-07-09 At 2014-07-09 01:10:03, "Alex Harui" wrote: >Hi Erik, > >Thanks for the list. I think this is a valuable discussion. I'm going to >respond out of order: hopefully the easiest answers first. Then at the >end is more of my continually evolving thoughts on FlexJS that may be hard >to capture from the slides. > >First, keep in mind that one of the FlexJS goals is to support multiple >component sets. Unlike current Flex's Spark or MX, the "basic" components >isn't intended to be a one-size-fits-all component set. There are already >the beginnings of component sets for JQUery and CreateJS and Cordova. > >Anyway, regarding #4 (MVC). I originally thought that there would be some >advantage when cross-compiling to having folks separate business and >controller logic from view. However, folks have complained about it, and >I haven't really seen any advantages so far so in FlexJS 0.0.3 or 0.0.4 >I'll probably remove the MVC requirement. Having the option of creating >single-file apps is much more friendly. > >#5 (lack of direction). I call that "exploring", but yeah, I don't have a >crystal ball to know where we need to end up. We are changing as we >discover things and our users provide feedback. I think that's a good >strategy and fits with the Apache Way. > >#1 (Migration Path). There is a migration path. I think it is very >similar to what you envision for your approach. You simply switch from a >current Flex SDK to a FlexJS SDK. You choose between replacing all mx and >spark prefixes or replacing just the URI in the xmlns. Could we add an >option to Falcon to override xmlns URIs? Sure, if that's what folks want. > >#2 (writing both AS and JS code). Actually, it is turning out that we are >not writing both AS and JS as much as I thought we would. The FlexJSJX >SWC and components like DataGrid and BarChart don't have any JS >equivalents in the repo. The AS in that SWC is cross-compiled. It is >looking like lots of components are "higher-level" and can be composed of >widgets from the FlexJSUI SWC. But yes, we are writing enough AS so the >SWF version is operational. This should provide several developer >benefits: runtime verification of your code for highly dynamic >applications, reduced testing if you can deploy SWFs on most browsers, a >way to support older browsers. > >#3 (beads). There is no requirement that the application developers have >to deal with a ton of beads. Only component developers that want to make >general-purpose components may want to take advantage of beads. The >"basic" components Peter and I (and hopefully others someday) are working >on are trying to leverage beads in order to make sure there is clean >separation of concerns in the framework code (vs 13,000 line base classes) >so that some of these pieces can be re-used for other component sets. >Then we're testing the waters to see whether application developers like >beads or not. If not, we can always "bake-in" beads into higher-level >components. But at least we'll know that if someone is desperately trying >to shave off code it is possible. > >And from your other post about GCC optimization: Maybe download size >doesn't matter and maybe GCC is so good you can add more code without any >performance and size implications, but that sort of defies logic to me. >It has been my experience that frameworks grow over time as you add >features and fix bugs. And it has been my experience that folks will give >up on frameworks for size and performance. That's why a significant >number of mobile AIR apps do not use Flex and are written in bare-bones >AS. I want Apache Flex to have a next-generation framework composed of >pieces so fewer fol
Re: New Flex to JS project
Hi Erik, Thanks for the list. I think this is a valuable discussion. I'm going to respond out of order: hopefully the easiest answers first. Then at the end is more of my continually evolving thoughts on FlexJS that may be hard to capture from the slides. First, keep in mind that one of the FlexJS goals is to support multiple component sets. Unlike current Flex's Spark or MX, the "basic" components isn't intended to be a one-size-fits-all component set. There are already the beginnings of component sets for JQUery and CreateJS and Cordova. Anyway, regarding #4 (MVC). I originally thought that there would be some advantage when cross-compiling to having folks separate business and controller logic from view. However, folks have complained about it, and I haven't really seen any advantages so far so in FlexJS 0.0.3 or 0.0.4 I'll probably remove the MVC requirement. Having the option of creating single-file apps is much more friendly. #5 (lack of direction). I call that "exploring", but yeah, I don't have a crystal ball to know where we need to end up. We are changing as we discover things and our users provide feedback. I think that's a good strategy and fits with the Apache Way. #1 (Migration Path). There is a migration path. I think it is very similar to what you envision for your approach. You simply switch from a current Flex SDK to a FlexJS SDK. You choose between replacing all mx and spark prefixes or replacing just the URI in the xmlns. Could we add an option to Falcon to override xmlns URIs? Sure, if that's what folks want. #2 (writing both AS and JS code). Actually, it is turning out that we are not writing both AS and JS as much as I thought we would. The FlexJSJX SWC and components like DataGrid and BarChart don't have any JS equivalents in the repo. The AS in that SWC is cross-compiled. It is looking like lots of components are "higher-level" and can be composed of widgets from the FlexJSUI SWC. But yes, we are writing enough AS so the SWF version is operational. This should provide several developer benefits: runtime verification of your code for highly dynamic applications, reduced testing if you can deploy SWFs on most browsers, a way to support older browsers. #3 (beads). There is no requirement that the application developers have to deal with a ton of beads. Only component developers that want to make general-purpose components may want to take advantage of beads. The "basic" components Peter and I (and hopefully others someday) are working on are trying to leverage beads in order to make sure there is clean separation of concerns in the framework code (vs 13,000 line base classes) so that some of these pieces can be re-used for other component sets. Then we're testing the waters to see whether application developers like beads or not. If not, we can always "bake-in" beads into higher-level components. But at least we'll know that if someone is desperately trying to shave off code it is possible. And from your other post about GCC optimization: Maybe download size doesn't matter and maybe GCC is so good you can add more code without any performance and size implications, but that sort of defies logic to me. It has been my experience that frameworks grow over time as you add features and fix bugs. And it has been my experience that folks will give up on frameworks for size and performance. That's why a significant number of mobile AIR apps do not use Flex and are written in bare-bones AS. I want Apache Flex to have a next-generation framework composed of pieces so fewer folks have to bail out. As we add more features to FlexJS, I hope the examples don't grow in size. IMO, they will for your VJS implementation because eventually, the VJS Button needs to wire in the code for tooltips even on mobile apps that will never use them. Or a heavy ResourceManager implementation for apps that only need to localize strings. There are 120+ public APIs on Spark Button most apps only use a small fraction. Another thing about FlexJS that has evolved over time is that I am thinking that the key advantage of FlexJS is simply in being the best way to glue JS together into an application. The "basic" components will be useful to many, but some folks have requirements to use certain JS frameworks. With the SWF version checking your code at runtime, with MXML giving you a schematic diagram, I hope to see component sets for Angular and other JS frameworks as well as the filling out of the Jquery and CreateJS sets, and possible different back-ends outputting to TypeScript and/or Dart. The beads create highly re-usable pieces for folks to build out these component sets and the result has little overhead compared to a manual port to that same JS framework. I believe we will always be compared to how fast and small a true JS application will be. So, the way I see it based on my understanding of the VJS approach you want to take is that you are just building another com
Re: New Flex to JS project
Also, between the Closure Compiler's effectiveness in optimising and minifying code and the current state of internet speed available to users, I think that 'application size' is not a major reason to make drastic decisions when architecting a framework. The release version of DatabindingTest is currently 70 kb, which basically means that is about a 10th the size of an average Facebook post. I mean, even if my approach would double the size - doubtful given GCCs effectiveness - it would still be something which you can download as easily as a single image from any website. EdB On Tue, Jul 8, 2014 at 1:03 PM, Erik de Bruin wrote: > Peter, > > To be sure, I'm not criticising the work done on FlexJS - I did a fair bit > of it myself - I'm just (after Alex's insistence) stating the reasons I've > chosen to approach 'export to JS' from a different angle. > > EdB > > > > > On Tue, Jul 8, 2014 at 12:57 PM, Peter Ent wrote: > >> I'm sure Alex is composing a longer response, but I wanted to chime in >> having developed a number of beads and components of FlexJS. >> >> FlexJS is designed to be a pay-as-go system, keeping the app size as >> small as possible; even a small Flex app brings in a lot of code. >> >> I have to agree that beads should be more generic and easier to connect. >> The reason for many beads is so you can add on just the functionality you >> need. Perhaps having a reduced number of beads that are more generic would >> make it easier to choose. Then, if you found yourself using the same >> combination repeatedly, you would make this a custom component in your app. >> >> And yes, the examples only go so far and new things have appeared. This >> is at alpha stage so there will be iterations. We needed to get sufficient >> components together so we could survey how it all hangs together. >> >> We are hoping more people will join the project and help with the >> direction and development. >> >> I think the core idea is sound and could use some tweaking. >> >> Peter >> >> >> > On Jul 8, 2014, at 6:11 AM, "DarkStone" wrote: >> > >> > Hi Erik, >> > >> > Thank you very much for bringing this topic, it's the very topic I want >> to share my thoughts on. >> > >> >> 3 - Strands/Beads: it forces developers to know the insides of >> components, >> >> adding a level of complexity and a steeper learning curve to the >> framework >> >> 4 - forced MVC: as an option it would be great, as a 'feature' not so >> much: >> >> it makes smaller projects unnecessarily complicated (e.g. all examples) >> > >> > I totally agree all the 5 points you've made, especially the 2 points >> above, I studied FlexJS' Strands/Beads MVC concept before, it forced me to >> do a restricted MVC application design. >> > >> > In most case, developers should have the abilities to design their own >> MVC concepts, rather than having to follow a pre-designed MVC concept. That >> is why Flex named itself "Flex", the flexibility is the soul of Flex, isn't >> it : ) >> > >> > I think Flex Spark's SkinnableComponent and Skin are good enough to >> separate a component's Logic and Skin. The Logic part of the component can >> then be divided into Model and Controller in anyway the developer want them >> to be, that is already the case in Flex Spark architecture, developers can >> decide how to design their own MVC concepts and apply them to their custom >> components, it's better this way. >> > >> > Besides, there are already a huge amount of projects based on the >> existing Flex Spark architecture, it will be much better if FlexJS can base >> on the Spark architecture, and makes the existing Flex projects much easier >> to transit to FlexJS. >> > >> > It took a very long time (over 10 years) to have Flex come this way, to >> make the Flex Spark architecture popular is already hard enough, so for the >> FlexJS, a smoother and easier transition from Flex to FlexJS is much needed! >> > >> > Well that is just my personal opinion, I know there are already a lot >> of hard works were put into the current FlexJS, and I am much appreciated, >> I will contribute what I can, when I can in the future, these months I'm >> gonna be very busy though. >> > >> > >> > DarkStone >> > 2014-07-08 >> > >> > >> > >> > At 2014-07-08 04:29:40, "Erik de Bruin" wrote: >> >> OK, here goes - why I think the FlexJS concept can be improved upon >> (in no >> >> particular order): >> >> >> >> 1 - there is no migration path for existing Flex applications; this >> will >> >> make enterprise users reluctant to accept the new framework, even >> though >> >> during development FlexJS is limiting itself because it aims to please >> the >> >> enterprise user (IE 'old' support) >> >> 2 - FlexJS requires a brand new framework on both the AS and JS side >> (apart >> >> from some stuff that may cross compile), effectively doubling the >> effort to >> >> bring it up to speed with other frameworks - including regular Flex >> >> 3 - Strands/Beads: it forces developers to know the inside
Re: New Flex to JS project
Peter, To be sure, I'm not criticising the work done on FlexJS - I did a fair bit of it myself - I'm just (after Alex's insistence) stating the reasons I've chosen to approach 'export to JS' from a different angle. EdB On Tue, Jul 8, 2014 at 12:57 PM, Peter Ent wrote: > I'm sure Alex is composing a longer response, but I wanted to chime in > having developed a number of beads and components of FlexJS. > > FlexJS is designed to be a pay-as-go system, keeping the app size as small > as possible; even a small Flex app brings in a lot of code. > > I have to agree that beads should be more generic and easier to connect. > The reason for many beads is so you can add on just the functionality you > need. Perhaps having a reduced number of beads that are more generic would > make it easier to choose. Then, if you found yourself using the same > combination repeatedly, you would make this a custom component in your app. > > And yes, the examples only go so far and new things have appeared. This is > at alpha stage so there will be iterations. We needed to get sufficient > components together so we could survey how it all hangs together. > > We are hoping more people will join the project and help with the > direction and development. > > I think the core idea is sound and could use some tweaking. > > Peter > > > > On Jul 8, 2014, at 6:11 AM, "DarkStone" wrote: > > > > Hi Erik, > > > > Thank you very much for bringing this topic, it's the very topic I want > to share my thoughts on. > > > >> 3 - Strands/Beads: it forces developers to know the insides of > components, > >> adding a level of complexity and a steeper learning curve to the > framework > >> 4 - forced MVC: as an option it would be great, as a 'feature' not so > much: > >> it makes smaller projects unnecessarily complicated (e.g. all examples) > > > > I totally agree all the 5 points you've made, especially the 2 points > above, I studied FlexJS' Strands/Beads MVC concept before, it forced me to > do a restricted MVC application design. > > > > In most case, developers should have the abilities to design their own > MVC concepts, rather than having to follow a pre-designed MVC concept. That > is why Flex named itself "Flex", the flexibility is the soul of Flex, isn't > it : ) > > > > I think Flex Spark's SkinnableComponent and Skin are good enough to > separate a component's Logic and Skin. The Logic part of the component can > then be divided into Model and Controller in anyway the developer want them > to be, that is already the case in Flex Spark architecture, developers can > decide how to design their own MVC concepts and apply them to their custom > components, it's better this way. > > > > Besides, there are already a huge amount of projects based on the > existing Flex Spark architecture, it will be much better if FlexJS can base > on the Spark architecture, and makes the existing Flex projects much easier > to transit to FlexJS. > > > > It took a very long time (over 10 years) to have Flex come this way, to > make the Flex Spark architecture popular is already hard enough, so for the > FlexJS, a smoother and easier transition from Flex to FlexJS is much needed! > > > > Well that is just my personal opinion, I know there are already a lot of > hard works were put into the current FlexJS, and I am much appreciated, I > will contribute what I can, when I can in the future, these months I'm > gonna be very busy though. > > > > > > DarkStone > > 2014-07-08 > > > > > > > > At 2014-07-08 04:29:40, "Erik de Bruin" wrote: > >> OK, here goes - why I think the FlexJS concept can be improved upon (in > no > >> particular order): > >> > >> 1 - there is no migration path for existing Flex applications; this will > >> make enterprise users reluctant to accept the new framework, even though > >> during development FlexJS is limiting itself because it aims to please > the > >> enterprise user (IE 'old' support) > >> 2 - FlexJS requires a brand new framework on both the AS and JS side > (apart > >> from some stuff that may cross compile), effectively doubling the > effort to > >> bring it up to speed with other frameworks - including regular Flex > >> 3 - Strands/Beads: it forces developers to know the insides of > components, > >> adding a level of complexity and a steeper learning curve to the > framework > >> I - by the time there are enough components/strands and beads to have > a > >> useful framework, the set of beads will be too big to easily work with > >> (e.g. "org.apache.flex.html.beads.DataItemRendererFactoryForArrayData" > or > >> > "org.apache.flex.html.beads.controllers.ListSingleSelectionMouseController") > >> II - making beads work on all strands makes beads complicated; making > >> beads that don't work on all strands makes beads confusing for the > developer > >> 4 - forced MVC: as an option it would be great, as a 'feature' not so > much: > >> it makes smaller projects unnecessarily complicated (e.g. all examples) > >> 5 - lack of
Re: New Flex to JS project
I'm sure Alex is composing a longer response, but I wanted to chime in having developed a number of beads and components of FlexJS. FlexJS is designed to be a pay-as-go system, keeping the app size as small as possible; even a small Flex app brings in a lot of code. I have to agree that beads should be more generic and easier to connect. The reason for many beads is so you can add on just the functionality you need. Perhaps having a reduced number of beads that are more generic would make it easier to choose. Then, if you found yourself using the same combination repeatedly, you would make this a custom component in your app. And yes, the examples only go so far and new things have appeared. This is at alpha stage so there will be iterations. We needed to get sufficient components together so we could survey how it all hangs together. We are hoping more people will join the project and help with the direction and development. I think the core idea is sound and could use some tweaking. Peter > On Jul 8, 2014, at 6:11 AM, "DarkStone" wrote: > > Hi Erik, > > Thank you very much for bringing this topic, it's the very topic I want to > share my thoughts on. > >> 3 - Strands/Beads: it forces developers to know the insides of components, >> adding a level of complexity and a steeper learning curve to the framework >> 4 - forced MVC: as an option it would be great, as a 'feature' not so much: >> it makes smaller projects unnecessarily complicated (e.g. all examples) > > I totally agree all the 5 points you've made, especially the 2 points above, > I studied FlexJS' Strands/Beads MVC concept before, it forced me to do a > restricted MVC application design. > > In most case, developers should have the abilities to design their own MVC > concepts, rather than having to follow a pre-designed MVC concept. That is > why Flex named itself "Flex", the flexibility is the soul of Flex, isn't it : > ) > > I think Flex Spark's SkinnableComponent and Skin are good enough to separate > a component's Logic and Skin. The Logic part of the component can then be > divided into Model and Controller in anyway the developer want them to be, > that is already the case in Flex Spark architecture, developers can decide > how to design their own MVC concepts and apply them to their custom > components, it's better this way. > > Besides, there are already a huge amount of projects based on the existing > Flex Spark architecture, it will be much better if FlexJS can base on the > Spark architecture, and makes the existing Flex projects much easier to > transit to FlexJS. > > It took a very long time (over 10 years) to have Flex come this way, to make > the Flex Spark architecture popular is already hard enough, so for the > FlexJS, a smoother and easier transition from Flex to FlexJS is much needed! > > Well that is just my personal opinion, I know there are already a lot of hard > works were put into the current FlexJS, and I am much appreciated, I will > contribute what I can, when I can in the future, these months I'm gonna be > very busy though. > > > DarkStone > 2014-07-08 > > > > At 2014-07-08 04:29:40, "Erik de Bruin" wrote: >> OK, here goes - why I think the FlexJS concept can be improved upon (in no >> particular order): >> >> 1 - there is no migration path for existing Flex applications; this will >> make enterprise users reluctant to accept the new framework, even though >> during development FlexJS is limiting itself because it aims to please the >> enterprise user (IE 'old' support) >> 2 - FlexJS requires a brand new framework on both the AS and JS side (apart >> from some stuff that may cross compile), effectively doubling the effort to >> bring it up to speed with other frameworks - including regular Flex >> 3 - Strands/Beads: it forces developers to know the insides of components, >> adding a level of complexity and a steeper learning curve to the framework >> I - by the time there are enough components/strands and beads to have a >> useful framework, the set of beads will be too big to easily work with >> (e.g. "org.apache.flex.html.beads.DataItemRendererFactoryForArrayData" or >> "org.apache.flex.html.beads.controllers.ListSingleSelectionMouseController") >> II - making beads work on all strands makes beads complicated; making >> beads that don't work on all strands makes beads confusing for the developer >> 4 - forced MVC: as an option it would be great, as a 'feature' not so much: >> it makes smaller projects unnecessarily complicated (e.g. all examples) >> 5 - lack of direction: FlexJS is a collection of proofs of concept, created >> top down to make nice looking demos that are then abandoned or superseded >> by other proofs of concept or demos. >> >> I think we already have a pretty nice AS framework, the Flex SDK, which I >> intend to offer as-is. Rather, I plan to make the 'export to JS' feature a >> part of the regular Flex SDK. That way the user can op
Re:Re: New Flex to JS project
Hi Erik, Thank you very much for bringing this topic, it's the very topic I want to share my thoughts on. >3 - Strands/Beads: it forces developers to know the insides of components, >adding a level of complexity and a steeper learning curve to the framework >4 - forced MVC: as an option it would be great, as a 'feature' not so much: >it makes smaller projects unnecessarily complicated (e.g. all examples) I totally agree all the 5 points you've made, especially the 2 points above, I studied FlexJS' Strands/Beads MVC concept before, it forced me to do a restricted MVC application design. In most case, developers should have the abilities to design their own MVC concepts, rather than having to follow a pre-designed MVC concept. That is why Flex named itself "Flex", the flexibility is the soul of Flex, isn't it : ) I think Flex Spark's SkinnableComponent and Skin are good enough to separate a component's Logic and Skin. The Logic part of the component can then be divided into Model and Controller in anyway the developer want them to be, that is already the case in Flex Spark architecture, developers can decide how to design their own MVC concepts and apply them to their custom components, it's better this way. Besides, there are already a huge amount of projects based on the existing Flex Spark architecture, it will be much better if FlexJS can base on the Spark architecture, and makes the existing Flex projects much easier to transit to FlexJS. It took a very long time (over 10 years) to have Flex come this way, to make the Flex Spark architecture popular is already hard enough, so for the FlexJS, a smoother and easier transition from Flex to FlexJS is much needed! Well that is just my personal opinion, I know there are already a lot of hard works were put into the current FlexJS, and I am much appreciated, I will contribute what I can, when I can in the future, these months I'm gonna be very busy though. DarkStone 2014-07-08 At 2014-07-08 04:29:40, "Erik de Bruin" wrote: >OK, here goes - why I think the FlexJS concept can be improved upon (in no >particular order): > >1 - there is no migration path for existing Flex applications; this will >make enterprise users reluctant to accept the new framework, even though >during development FlexJS is limiting itself because it aims to please the >enterprise user (IE 'old' support) >2 - FlexJS requires a brand new framework on both the AS and JS side (apart >from some stuff that may cross compile), effectively doubling the effort to >bring it up to speed with other frameworks - including regular Flex >3 - Strands/Beads: it forces developers to know the insides of components, >adding a level of complexity and a steeper learning curve to the framework >I - by the time there are enough components/strands and beads to have a >useful framework, the set of beads will be too big to easily work with >(e.g. "org.apache.flex.html.beads.DataItemRendererFactoryForArrayData" or >"org.apache.flex.html.beads.controllers.ListSingleSelectionMouseController") >II - making beads work on all strands makes beads complicated; making >beads that don't work on all strands makes beads confusing for the developer >4 - forced MVC: as an option it would be great, as a 'feature' not so much: >it makes smaller projects unnecessarily complicated (e.g. all examples) >5 - lack of direction: FlexJS is a collection of proofs of concept, created >top down to make nice looking demos that are then abandoned or superseded >by other proofs of concept or demos. > >I think we already have a pretty nice AS framework, the Flex SDK, which I >intend to offer as-is. Rather, I plan to make the 'export to JS' feature a >part of the regular Flex SDK. That way the user can open any Flex project, >run the export and get a fully functional, identical looking application in >JS, or, worst case, a nice list from the compiler explaining which >components/properties don't (yet) work in JS and how to fix that. > >I'm interested to hear more about how you think this approach is related to >FlexJS. If there is any synergy to be had, I'm all for it! > >EdB > > > >On Mon, Jul 7, 2014 at 6:27 PM, Alex Harui wrote: > >> I'm not sure what you mean by "philosophical". I see more similarities >> than differences between FlexJS and your approach of trying to mimic more >> of the current SDK in JS. In fact, I still hope to convince you that what >> you want to do is within the FlexJS charter so we can work together >> instead appearing to work on separate efforts. And then what you are >> working on would also be weakened by whatever it is you want to say. If >> you have a killer argument why folks should not be trying to compile MXML >> and AS to JS, I think the whole community will be better served by finding >> out why now. >> >> -Alex >> >> On 7/7/14 8:40 AM, "Erik de Bruin" wrote: >> >> >There are no technical issues per se that would need addressing to keep >> >FlexJS healthy. I made
Re: New Flex to JS project
OK, here goes - why I think the FlexJS concept can be improved upon (in no particular order): 1 - there is no migration path for existing Flex applications; this will make enterprise users reluctant to accept the new framework, even though during development FlexJS is limiting itself because it aims to please the enterprise user (IE 'old' support) 2 - FlexJS requires a brand new framework on both the AS and JS side (apart from some stuff that may cross compile), effectively doubling the effort to bring it up to speed with other frameworks - including regular Flex 3 - Strands/Beads: it forces developers to know the insides of components, adding a level of complexity and a steeper learning curve to the framework I - by the time there are enough components/strands and beads to have a useful framework, the set of beads will be too big to easily work with (e.g. "org.apache.flex.html.beads.DataItemRendererFactoryForArrayData" or "org.apache.flex.html.beads.controllers.ListSingleSelectionMouseController") II - making beads work on all strands makes beads complicated; making beads that don't work on all strands makes beads confusing for the developer 4 - forced MVC: as an option it would be great, as a 'feature' not so much: it makes smaller projects unnecessarily complicated (e.g. all examples) 5 - lack of direction: FlexJS is a collection of proofs of concept, created top down to make nice looking demos that are then abandoned or superseded by other proofs of concept or demos. I think we already have a pretty nice AS framework, the Flex SDK, which I intend to offer as-is. Rather, I plan to make the 'export to JS' feature a part of the regular Flex SDK. That way the user can open any Flex project, run the export and get a fully functional, identical looking application in JS, or, worst case, a nice list from the compiler explaining which components/properties don't (yet) work in JS and how to fix that. I'm interested to hear more about how you think this approach is related to FlexJS. If there is any synergy to be had, I'm all for it! EdB On Mon, Jul 7, 2014 at 6:27 PM, Alex Harui wrote: > I'm not sure what you mean by "philosophical". I see more similarities > than differences between FlexJS and your approach of trying to mimic more > of the current SDK in JS. In fact, I still hope to convince you that what > you want to do is within the FlexJS charter so we can work together > instead appearing to work on separate efforts. And then what you are > working on would also be weakened by whatever it is you want to say. If > you have a killer argument why folks should not be trying to compile MXML > and AS to JS, I think the whole community will be better served by finding > out why now. > > -Alex > > On 7/7/14 8:40 AM, "Erik de Bruin" wrote: > > >There are no technical issues per se that would need addressing to keep > >FlexJS healthy. I made sure of that. > > > >My argument is basically philosophical, and I think my ranting about it in > >public would weaken FlexJS' case, so I won't. > > > >EdB > > > > > > > >On Thu, Jul 3, 2014 at 4:47 PM, Alex Harui wrote: > > > >> I think it has to be in public. This is open development. I'm hoping > >>you > >> will save me time by doing so. If we are doing something we shouldn't > >>we > >> should correct it now otherwise we'll waste time and energy doing more > >> work in that direction only to find out that customers have the same > >> feedback. > >> > >> Not that all of your feedback is guaranteed to be addressed: there's > >> always a chance that what you don't like is philosophical rather than > >> technical. That's why there are dozens of JS frameworks already and why > >> you want to try a different approach. > >> > >> -Alex > >> > >> On 7/3/14 12:00 AM, "Erik de Bruin" wrote: > >> > >> >You want to hear that in public, or do you want to take this off list? > >> > > >> >EdB > >> > > >> > > >> > > >> > > >> >On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui wrote: > >> > > >> >> > >> >> > >> >> > >> >> >I've been doing that as well for the last couple of years. I spent > >> >>most of > >> >> >my time getting FlexJS off the ground. But I don't agree with some > >>of > >> >>the > >> >> >basic assumptions and choices that FlexJS has made. I said little or > >> >> >nothing about it to give FlexJS a proper head start and to keep you > >>and > >> >> >Peter going. But now that I have re-evaluated what the project > >>means to > >> >> >me, > >> >> >and what I would like to spend my time on when contributing, and I > >> >>have to > >> >> >give my take on Flex to JS a try. > >> >> I'd love to hear your thoughts on what you don't agree with regarding > >> >> FlexJS. > >> >> > >> >> -Alex > >> >> > >> >> > >> > > >> > > >> >-- > >> >Ix Multimedia Software > >> > > >> >Jan Luykenstraat 27 > >> >3521 VB Utrecht > >> > > >> >T. 06-51952295 > >> >I. www.ixsoftware.nl > >> > >> > > > > > >-- > >Ix Multimedia Software > > > >Jan Luykenstraat 27 > >3521 VB Utrecht > >
Re: New Flex to JS project
I'm not sure what you mean by "philosophical". I see more similarities than differences between FlexJS and your approach of trying to mimic more of the current SDK in JS. In fact, I still hope to convince you that what you want to do is within the FlexJS charter so we can work together instead appearing to work on separate efforts. And then what you are working on would also be weakened by whatever it is you want to say. If you have a killer argument why folks should not be trying to compile MXML and AS to JS, I think the whole community will be better served by finding out why now. -Alex On 7/7/14 8:40 AM, "Erik de Bruin" wrote: >There are no technical issues per se that would need addressing to keep >FlexJS healthy. I made sure of that. > >My argument is basically philosophical, and I think my ranting about it in >public would weaken FlexJS' case, so I won't. > >EdB > > > >On Thu, Jul 3, 2014 at 4:47 PM, Alex Harui wrote: > >> I think it has to be in public. This is open development. I'm hoping >>you >> will save me time by doing so. If we are doing something we shouldn't >>we >> should correct it now otherwise we'll waste time and energy doing more >> work in that direction only to find out that customers have the same >> feedback. >> >> Not that all of your feedback is guaranteed to be addressed: there's >> always a chance that what you don't like is philosophical rather than >> technical. That's why there are dozens of JS frameworks already and why >> you want to try a different approach. >> >> -Alex >> >> On 7/3/14 12:00 AM, "Erik de Bruin" wrote: >> >> >You want to hear that in public, or do you want to take this off list? >> > >> >EdB >> > >> > >> > >> > >> >On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui wrote: >> > >> >> >> >> >> >> >> >> >I've been doing that as well for the last couple of years. I spent >> >>most of >> >> >my time getting FlexJS off the ground. But I don't agree with some >>of >> >>the >> >> >basic assumptions and choices that FlexJS has made. I said little or >> >> >nothing about it to give FlexJS a proper head start and to keep you >>and >> >> >Peter going. But now that I have re-evaluated what the project >>means to >> >> >me, >> >> >and what I would like to spend my time on when contributing, and I >> >>have to >> >> >give my take on Flex to JS a try. >> >> I'd love to hear your thoughts on what you don't agree with regarding >> >> FlexJS. >> >> >> >> -Alex >> >> >> >> >> > >> > >> >-- >> >Ix Multimedia Software >> > >> >Jan Luykenstraat 27 >> >3521 VB Utrecht >> > >> >T. 06-51952295 >> >I. www.ixsoftware.nl >> >> > > >-- >Ix Multimedia Software > >Jan Luykenstraat 27 >3521 VB Utrecht > >T. 06-51952295 >I. www.ixsoftware.nl
Re: New Flex to JS project
There are no technical issues per se that would need addressing to keep FlexJS healthy. I made sure of that. My argument is basically philosophical, and I think my ranting about it in public would weaken FlexJS' case, so I won't. EdB On Thu, Jul 3, 2014 at 4:47 PM, Alex Harui wrote: > I think it has to be in public. This is open development. I'm hoping you > will save me time by doing so. If we are doing something we shouldn't we > should correct it now otherwise we'll waste time and energy doing more > work in that direction only to find out that customers have the same > feedback. > > Not that all of your feedback is guaranteed to be addressed: there's > always a chance that what you don't like is philosophical rather than > technical. That's why there are dozens of JS frameworks already and why > you want to try a different approach. > > -Alex > > On 7/3/14 12:00 AM, "Erik de Bruin" wrote: > > >You want to hear that in public, or do you want to take this off list? > > > >EdB > > > > > > > > > >On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui wrote: > > > >> > >> > >> > >> >I've been doing that as well for the last couple of years. I spent > >>most of > >> >my time getting FlexJS off the ground. But I don't agree with some of > >>the > >> >basic assumptions and choices that FlexJS has made. I said little or > >> >nothing about it to give FlexJS a proper head start and to keep you and > >> >Peter going. But now that I have re-evaluated what the project means to > >> >me, > >> >and what I would like to spend my time on when contributing, and I > >>have to > >> >give my take on Flex to JS a try. > >> I'd love to hear your thoughts on what you don't agree with regarding > >> FlexJS. > >> > >> -Alex > >> > >> > > > > > >-- > >Ix Multimedia Software > > > >Jan Luykenstraat 27 > >3521 VB Utrecht > > > >T. 06-51952295 > >I. www.ixsoftware.nl > > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: New Flex to JS project
And I've been meaning to see if anyone has invented a proxy server that
does this sort of thing.
I'm still not convinced the compiler can convert e4x to these calls. We
can if we force folks to strongly type everything, but I'd bet a lot of
existing code is not strongly-typed enough. For example:
Class CustomItemRenderer
{
Public function get data():Object
{
Return _data;
}
}
If the CustomItemRenderer is used for an XMLListCollection, the data will
be XML but the compiler will not know that.
But yes, you are welcome to pursue making more of folks' XML code work in
FlexJS without porting.
-Alex
On 7/6/14 10:52 PM, "Harbs" wrote:
>I used the wrong link. It should have been:
>https://developer.mozilla.org/en-US/docs/JXON
>
>On Jul 7, 2014, at 8:50 AM, Harbs wrote:
>
>> I was thinking of creating a class which stores the xml structure
>>internally as javascript objects using these methods [1]
>>
>> Then we could build on top of that all the standard E4X functions for
>>accessing nodes and attributes.
>>
>> Dot notation would be complex (or impossible) to handle natively, but I
>>imagine FlaconJS could handle E4X dot notation as special cases and call
>>.child() and .attribute() respectively.
>>
>> This should solve the performance concerns with using XML (because it
>>would be native js objects under the hood), but allow E4X type of
>>functionality.
>>
>> I would not have a clue of how to go about handling the dot notation in
>>FlaconJS, but the first part should be pretty straight-forward.
>>
>> [1]
>>https://developer.mozilla.org/en-US/docs/Web/Guide/Parsing_and_serializin
>>g_XML
>>
>> On Jul 7, 2014, at 8:27 AM, OmPrakash Muppirala
>>wrote:
>>
>>> On Sun, Jul 6, 2014 at 10:12 PM, Alex Harui wrote:
>>>
On 7/6/14 9:54 PM, "OmPrakash Muppirala" wrote:
> On Sun, Jul 6, 2014 at 9:49 PM, Alex Harui wrote:
>
>> I certainly won't stop someone from trying to implement e4x in JS.
>>I
>> think there may already be some attempts. I think a significant
>>number
>> of
>> folks use dot-path like Mark Kessler reported and so it will still
>>be a
>> porting challenge for folks to re-code to using functions.
>>
>> That's why it isn't on my priority list: if you're going to port
>>your
>> e4x
>> dot-path expressions, it might just be better to go to JSON instead.
>
>
> Switching from XML to JSON will require a server side change in most
> scenarios. That might not be an option for folks especially servers
>that
> they don't have control over.
This is true, but one of the philosophies of FlexJS is "would you
have had
to convert anyway?". At least a couple potential FlexJS customers
have
already built out JSON backends as they explore which JS migration
strategy to take. It appears that, at least for those folks, the
notion
of using XML in JS is too nasty and it is worth the time to change the
backend.
>>>
>>> Things like public Atom, RSS feeds do require XML processing. Another
>>> scenario is where I wanted to try out my hand at exporting an Adobe
>>> Illustrator file to .FXG. Now that the Creative Cloud extensions are
>>> HTML(5) based, that seems like a good target for FlexJS. If XML is not
>>> supported, this use case is a non-starter.
>>>
>>>
For others who really truly can't port the backend, it might be worth
the
time to convert from XML to Object, similar to the way the
SOAPDecoder and
XMLDecoders work today. XML has always been much slower and memory
intensive in Flash and often folks convert to classes/objects.
FlexJS has
support for that already, although there is no generic SOAPDecoder or
XMLDecoder.
>>>
>>> I think mx.rpc.xml.SimpleXMLDecoder should lend itself to FlexJS quite
>>> well. Not exactly E4X, but at least it brings makes it closer to JSON.
>>> What do you think?
>>>
>>>
But again, anyone is welcome to take on trying to support e4x in JS.
-Alex
>>
>
Re: New Flex to JS project
On 7/6/14 10:27 PM, "OmPrakash Muppirala" wrote: > >Things like public Atom, RSS feeds do require XML processing. I would assume someone has successfully handles RSS in JS already, probably by using whatever XML apis are there. And that is always an option, but I believe Flash and JS XML APIs are different enough to make that a painful cross-compile. But attempts at that are welcome as well. >Another >scenario is where I wanted to try out my hand at exporting an Adobe >Illustrator file to .FXG. Now that the Creative Cloud extensions are >HTML(5) based, that seems like a good target for FlexJS. Thanks for reminding me to ping the CC Extensions folks after we ship FlexJS 0.0.2. I talked to them a while ago and they are interested. Harbs was the first person to pose the idea to them. > >> >> For others who really truly can't port the backend, it might be worth >>the >> time to convert from XML to Object, similar to the way the SOAPDecoder >>and >> XMLDecoders work today. XML has always been much slower and memory >> intensive in Flash and often folks convert to classes/objects. FlexJS >>has >> support for that already, although there is no generic SOAPDecoder or >> XMLDecoder. >> > >I think mx.rpc.xml.SimpleXMLDecoder should lend itself to FlexJS quite >well. Not exactly E4X, but at least it brings makes it closer to JSON. >What do you think? I think it might have some ties back to RPC, but yes, I would envision a "convert all" decoder like that, plus a "lazy" decode. I've seen the "convert all" freeze Flash for certain XML data sets. -Alex
Re: New Flex to JS project
I used the wrong link. It should have been: https://developer.mozilla.org/en-US/docs/JXON On Jul 7, 2014, at 8:50 AM, Harbs wrote: > I was thinking of creating a class which stores the xml structure internally > as javascript objects using these methods [1] > > Then we could build on top of that all the standard E4X functions for > accessing nodes and attributes. > > Dot notation would be complex (or impossible) to handle natively, but I > imagine FlaconJS could handle E4X dot notation as special cases and call > .child() and .attribute() respectively. > > This should solve the performance concerns with using XML (because it would > be native js objects under the hood), but allow E4X type of functionality. > > I would not have a clue of how to go about handling the dot notation in > FlaconJS, but the first part should be pretty straight-forward. > > [1] > https://developer.mozilla.org/en-US/docs/Web/Guide/Parsing_and_serializing_XML > > On Jul 7, 2014, at 8:27 AM, OmPrakash Muppirala wrote: > >> On Sun, Jul 6, 2014 at 10:12 PM, Alex Harui wrote: >> >>> >>> >>> On 7/6/14 9:54 PM, "OmPrakash Muppirala" wrote: >>> On Sun, Jul 6, 2014 at 9:49 PM, Alex Harui wrote: > I certainly won't stop someone from trying to implement e4x in JS. I > think there may already be some attempts. I think a significant number > of > folks use dot-path like Mark Kessler reported and so it will still be a > porting challenge for folks to re-code to using functions. > > That's why it isn't on my priority list: if you're going to port your > e4x > dot-path expressions, it might just be better to go to JSON instead. Switching from XML to JSON will require a server side change in most scenarios. That might not be an option for folks especially servers that they don't have control over. >>> This is true, but one of the philosophies of FlexJS is "would you have had >>> to convert anyway?". At least a couple potential FlexJS customers have >>> already built out JSON backends as they explore which JS migration >>> strategy to take. It appears that, at least for those folks, the notion >>> of using XML in JS is too nasty and it is worth the time to change the >>> backend. >>> >> >> Things like public Atom, RSS feeds do require XML processing. Another >> scenario is where I wanted to try out my hand at exporting an Adobe >> Illustrator file to .FXG. Now that the Creative Cloud extensions are >> HTML(5) based, that seems like a good target for FlexJS. If XML is not >> supported, this use case is a non-starter. >> >> >>> >>> For others who really truly can't port the backend, it might be worth the >>> time to convert from XML to Object, similar to the way the SOAPDecoder and >>> XMLDecoders work today. XML has always been much slower and memory >>> intensive in Flash and often folks convert to classes/objects. FlexJS has >>> support for that already, although there is no generic SOAPDecoder or >>> XMLDecoder. >>> >> >> I think mx.rpc.xml.SimpleXMLDecoder should lend itself to FlexJS quite >> well. Not exactly E4X, but at least it brings makes it closer to JSON. >> What do you think? >> >> >>> >>> But again, anyone is welcome to take on trying to support e4x in JS. >>> >>> -Alex >
Re: New Flex to JS project
I was thinking of creating a class which stores the xml structure internally as javascript objects using these methods [1] Then we could build on top of that all the standard E4X functions for accessing nodes and attributes. Dot notation would be complex (or impossible) to handle natively, but I imagine FlaconJS could handle E4X dot notation as special cases and call .child() and .attribute() respectively. This should solve the performance concerns with using XML (because it would be native js objects under the hood), but allow E4X type of functionality. I would not have a clue of how to go about handling the dot notation in FlaconJS, but the first part should be pretty straight-forward. [1] https://developer.mozilla.org/en-US/docs/Web/Guide/Parsing_and_serializing_XML On Jul 7, 2014, at 8:27 AM, OmPrakash Muppirala wrote: > On Sun, Jul 6, 2014 at 10:12 PM, Alex Harui wrote: > >> >> >> On 7/6/14 9:54 PM, "OmPrakash Muppirala" wrote: >> >>> On Sun, Jul 6, 2014 at 9:49 PM, Alex Harui wrote: >>> I certainly won't stop someone from trying to implement e4x in JS. I think there may already be some attempts. I think a significant number of folks use dot-path like Mark Kessler reported and so it will still be a porting challenge for folks to re-code to using functions. That's why it isn't on my priority list: if you're going to port your e4x dot-path expressions, it might just be better to go to JSON instead. >>> >>> >>> Switching from XML to JSON will require a server side change in most >>> scenarios. That might not be an option for folks especially servers that >>> they don't have control over. >> This is true, but one of the philosophies of FlexJS is "would you have had >> to convert anyway?". At least a couple potential FlexJS customers have >> already built out JSON backends as they explore which JS migration >> strategy to take. It appears that, at least for those folks, the notion >> of using XML in JS is too nasty and it is worth the time to change the >> backend. >> > > Things like public Atom, RSS feeds do require XML processing. Another > scenario is where I wanted to try out my hand at exporting an Adobe > Illustrator file to .FXG. Now that the Creative Cloud extensions are > HTML(5) based, that seems like a good target for FlexJS. If XML is not > supported, this use case is a non-starter. > > >> >> For others who really truly can't port the backend, it might be worth the >> time to convert from XML to Object, similar to the way the SOAPDecoder and >> XMLDecoders work today. XML has always been much slower and memory >> intensive in Flash and often folks convert to classes/objects. FlexJS has >> support for that already, although there is no generic SOAPDecoder or >> XMLDecoder. >> > > I think mx.rpc.xml.SimpleXMLDecoder should lend itself to FlexJS quite > well. Not exactly E4X, but at least it brings makes it closer to JSON. > What do you think? > > >> >> But again, anyone is welcome to take on trying to support e4x in JS. >> >> -Alex
Re: New Flex to JS project
On Sun, Jul 6, 2014 at 10:12 PM, Alex Harui wrote: > > > On 7/6/14 9:54 PM, "OmPrakash Muppirala" wrote: > > >On Sun, Jul 6, 2014 at 9:49 PM, Alex Harui wrote: > > > >> I certainly won't stop someone from trying to implement e4x in JS. I > >> think there may already be some attempts. I think a significant number > >>of > >> folks use dot-path like Mark Kessler reported and so it will still be a > >> porting challenge for folks to re-code to using functions. > >> > >> That's why it isn't on my priority list: if you're going to port your > >>e4x > >> dot-path expressions, it might just be better to go to JSON instead. > > > > > >Switching from XML to JSON will require a server side change in most > >scenarios. That might not be an option for folks especially servers that > >they don't have control over. > This is true, but one of the philosophies of FlexJS is "would you have had > to convert anyway?". At least a couple potential FlexJS customers have > already built out JSON backends as they explore which JS migration > strategy to take. It appears that, at least for those folks, the notion > of using XML in JS is too nasty and it is worth the time to change the > backend. > Things like public Atom, RSS feeds do require XML processing. Another scenario is where I wanted to try out my hand at exporting an Adobe Illustrator file to .FXG. Now that the Creative Cloud extensions are HTML(5) based, that seems like a good target for FlexJS. If XML is not supported, this use case is a non-starter. > > For others who really truly can't port the backend, it might be worth the > time to convert from XML to Object, similar to the way the SOAPDecoder and > XMLDecoders work today. XML has always been much slower and memory > intensive in Flash and often folks convert to classes/objects. FlexJS has > support for that already, although there is no generic SOAPDecoder or > XMLDecoder. > I think mx.rpc.xml.SimpleXMLDecoder should lend itself to FlexJS quite well. Not exactly E4X, but at least it brings makes it closer to JSON. What do you think? > > But again, anyone is welcome to take on trying to support e4x in JS. > > -Alex > >
Re: New Flex to JS project
On 7/6/14 9:54 PM, "OmPrakash Muppirala" wrote: >On Sun, Jul 6, 2014 at 9:49 PM, Alex Harui wrote: > >> I certainly won't stop someone from trying to implement e4x in JS. I >> think there may already be some attempts. I think a significant number >>of >> folks use dot-path like Mark Kessler reported and so it will still be a >> porting challenge for folks to re-code to using functions. >> >> That's why it isn't on my priority list: if you're going to port your >>e4x >> dot-path expressions, it might just be better to go to JSON instead. > > >Switching from XML to JSON will require a server side change in most >scenarios. That might not be an option for folks especially servers that >they don't have control over. This is true, but one of the philosophies of FlexJS is "would you have had to convert anyway?". At least a couple potential FlexJS customers have already built out JSON backends as they explore which JS migration strategy to take. It appears that, at least for those folks, the notion of using XML in JS is too nasty and it is worth the time to change the backend. For others who really truly can't port the backend, it might be worth the time to convert from XML to Object, similar to the way the SOAPDecoder and XMLDecoders work today. XML has always been much slower and memory intensive in Flash and often folks convert to classes/objects. FlexJS has support for that already, although there is no generic SOAPDecoder or XMLDecoder. But again, anyone is welcome to take on trying to support e4x in JS. -Alex
Re: New Flex to JS project
On Sun, Jul 6, 2014 at 9:49 PM, Alex Harui wrote:
> I certainly won't stop someone from trying to implement e4x in JS. I
> think there may already be some attempts. I think a significant number of
> folks use dot-path like Mark Kessler reported and so it will still be a
> porting challenge for folks to re-code to using functions.
>
> That's why it isn't on my priority list: if you're going to port your e4x
> dot-path expressions, it might just be better to go to JSON instead.
Switching from XML to JSON will require a server side change in most
scenarios. That might not be an option for folks especially servers that
they don't have control over.
Thanks,
Om
> I think any attempt to do e4x requires custom data objects with getters
> because there are many scenarios where it isn't clear to the compiler that
> you are compiling e4x. For example, as the data property in an item
> renderer.
>
> -Alex
>
> On 7/5/14 11:41 PM, "Harbs" wrote:
>
> >I think it is.
> >
> >Partial E4X support is better than none. We could offer support for the
> >more verbose form. I imagine it should be possible to do some conversions
> >of our own when compiling as well.
> >
> >I'm not sure how to go about handling filters though.
> >
> >On Jul 5, 2014, at 9:29 AM, Alex Harui wrote:
> >
> >> I've not looked to see if the compiler does that or the runtime. I
> >>think
> >> it is the runtime isn't it?
> >>
> >> -Alex
> >>
> >> On 7/4/14 10:12 AM, "Gordon Smith" wrote:
> >>
> >>> I think this syntax is just sugar for more verbose function calls like
> >>>
> >>> trace(foo.children("is"))
> >>>
> >>> but the terse syntax is much nicer.
> >>>
> >>> - Gordon
> >>>
> >>> Sent from my iPad
> >>>
> On Jul 4, 2014, at 12:22 AM, "Alex Harui" wrote:
>
> There are functions, but I've seen significant use of XML as an
> "Object".
> IMO it is what makes e4x possible: the dot-path lookup as below:
>
> Var foo:XML =
>
>
> Trace(foo.is);
> Trace(foo..a(@name=="test"));
> Trace(foo..test);
>
> But I could be wrong and there is some other way to handle this.
>
> -Alex
>
> > On 7/3/14 12:51 PM, "Harbs" wrote:
> >
> > Why does it need setter/getter? E4X is all functions isn't it?
> >
> > Yeah. JSON is generally a better way to go, but some APIs are still
> >XML
> > and then there's manipulation of XML documents (which I tend to do a
> > lot
> > of...)
> >
> >> On Jul 3, 2014, at 7:53 PM, Alex Harui wrote:
> >>
> >> I took a quick look a while back. Required getter/setter support in
> >> the
> >> browser. And then the remaining question: will it perform? It is
> >> similar
> >> to the AMF question. Doable, but may not be faster than switching
> >>to
> >> JSON.
> >>
> >> -Alex
> >>
> >>> On 7/3/14 9:48 AM, "Harbs" wrote:
> >>>
> >>> Has anyone looked into writing a js library to copy the
> >>>functionality
> >>> of
> >>> E4X?
> >>>
> >>> It seems to me that at least 90% of E4X could be pretty easily
> >>> replicated
> >>> in a js libraryŠ
> >>>
> >>> Besides namespaces, the only thing that seems hard to me is complex
> >>> selectors.
> >>>
> On Jul 2, 2014, at 7:53 PM, Alex Harui wrote:
>
> FWIW, FlexJS is eventually going to need to find a way to warn
> folks
> about
> use of E4X
> >>>
> >>
> >
>
> >>
> >
>
>
Re: New Flex to JS project
I certainly won't stop someone from trying to implement e4x in JS. I
think there may already be some attempts. I think a significant number of
folks use dot-path like Mark Kessler reported and so it will still be a
porting challenge for folks to re-code to using functions.
That's why it isn't on my priority list: if you're going to port your e4x
dot-path expressions, it might just be better to go to JSON instead. I
think any attempt to do e4x requires custom data objects with getters
because there are many scenarios where it isn't clear to the compiler that
you are compiling e4x. For example, as the data property in an item
renderer.
-Alex
On 7/5/14 11:41 PM, "Harbs" wrote:
>I think it is.
>
>Partial E4X support is better than none. We could offer support for the
>more verbose form. I imagine it should be possible to do some conversions
>of our own when compiling as well.
>
>I'm not sure how to go about handling filters though.
>
>On Jul 5, 2014, at 9:29 AM, Alex Harui wrote:
>
>> I've not looked to see if the compiler does that or the runtime. I
>>think
>> it is the runtime isn't it?
>>
>> -Alex
>>
>> On 7/4/14 10:12 AM, "Gordon Smith" wrote:
>>
>>> I think this syntax is just sugar for more verbose function calls like
>>>
>>> trace(foo.children("is"))
>>>
>>> but the terse syntax is much nicer.
>>>
>>> - Gordon
>>>
>>> Sent from my iPad
>>>
On Jul 4, 2014, at 12:22 AM, "Alex Harui" wrote:
There are functions, but I've seen significant use of XML as an
"Object".
IMO it is what makes e4x possible: the dot-path lookup as below:
Var foo:XML =
Trace(foo.is);
Trace(foo..a(@name=="test"));
Trace(foo..test);
But I could be wrong and there is some other way to handle this.
-Alex
> On 7/3/14 12:51 PM, "Harbs" wrote:
>
> Why does it need setter/getter? E4X is all functions isn't it?
>
> Yeah. JSON is generally a better way to go, but some APIs are still
>XML
> and then there's manipulation of XML documents (which I tend to do a
> lot
> of...)
>
>> On Jul 3, 2014, at 7:53 PM, Alex Harui wrote:
>>
>> I took a quick look a while back. Required getter/setter support in
>> the
>> browser. And then the remaining question: will it perform? It is
>> similar
>> to the AMF question. Doable, but may not be faster than switching
>>to
>> JSON.
>>
>> -Alex
>>
>>> On 7/3/14 9:48 AM, "Harbs" wrote:
>>>
>>> Has anyone looked into writing a js library to copy the
>>>functionality
>>> of
>>> E4X?
>>>
>>> It seems to me that at least 90% of E4X could be pretty easily
>>> replicated
>>> in a js libraryŠ
>>>
>>> Besides namespaces, the only thing that seems hard to me is complex
>>> selectors.
>>>
On Jul 2, 2014, at 7:53 PM, Alex Harui wrote:
FWIW, FlexJS is eventually going to need to find a way to warn
folks
about
use of E4X
>>>
>>
>
>>
>
Re: New Flex to JS project
I use tons of dot path references for xml/e4x. And much less frequently the inline filtering. -Mark On Fri, Jul 4, 2014 at 3:21 AM, Alex Harui wrote: > There are functions, but I've seen significant use of XML as an "Object". > IMO it is what makes e4x possible: the dot-path lookup as below: > > Var foo:XML = > > > Trace(foo.is); > Trace(foo..a(@name=="test")); > Trace(foo..test); > > But I could be wrong and there is some other way to handle this. > > -Alex >
Re: New Flex to JS project
I think it is.
Partial E4X support is better than none. We could offer support for the more
verbose form. I imagine it should be possible to do some conversions of our own
when compiling as well.
I’m not sure how to go about handling filters though.
On Jul 5, 2014, at 9:29 AM, Alex Harui wrote:
> I've not looked to see if the compiler does that or the runtime. I think
> it is the runtime isn't it?
>
> -Alex
>
> On 7/4/14 10:12 AM, "Gordon Smith" wrote:
>
>> I think this syntax is just sugar for more verbose function calls like
>>
>> trace(foo.children("is"))
>>
>> but the terse syntax is much nicer.
>>
>> - Gordon
>>
>> Sent from my iPad
>>
>>> On Jul 4, 2014, at 12:22 AM, "Alex Harui" wrote:
>>>
>>> There are functions, but I've seen significant use of XML as an
>>> "Object".
>>> IMO it is what makes e4x possible: the dot-path lookup as below:
>>>
>>> Var foo:XML =
>>>
>>>
>>> Trace(foo.is);
>>> Trace(foo..a(@name=="test"));
>>> Trace(foo..test);
>>>
>>> But I could be wrong and there is some other way to handle this.
>>>
>>> -Alex
>>>
On 7/3/14 12:51 PM, "Harbs" wrote:
Why does it need setter/getter? E4X is all functions isn't it?
Yeah. JSON is generally a better way to go, but some APIs are still XML
and then there's manipulation of XML documents (which I tend to do a
lot
of...)
> On Jul 3, 2014, at 7:53 PM, Alex Harui wrote:
>
> I took a quick look a while back. Required getter/setter support in
> the
> browser. And then the remaining question: will it perform? It is
> similar
> to the AMF question. Doable, but may not be faster than switching to
> JSON.
>
> -Alex
>
>> On 7/3/14 9:48 AM, "Harbs" wrote:
>>
>> Has anyone looked into writing a js library to copy the functionality
>> of
>> E4X?
>>
>> It seems to me that at least 90% of E4X could be pretty easily
>> replicated
>> in a js libraryŠ
>>
>> Besides namespaces, the only thing that seems hard to me is complex
>> selectors.
>>
>>> On Jul 2, 2014, at 7:53 PM, Alex Harui wrote:
>>>
>>> FWIW, FlexJS is eventually going to need to find a way to warn folks
>>> about
>>> use of E4X
>>
>
>>>
>
Re: New Flex to JS project
I've not looked to see if the compiler does that or the runtime. I think
it is the runtime isn't it?
-Alex
On 7/4/14 10:12 AM, "Gordon Smith" wrote:
>I think this syntax is just sugar for more verbose function calls like
>
>trace(foo.children("is"))
>
>but the terse syntax is much nicer.
>
>- Gordon
>
>Sent from my iPad
>
>> On Jul 4, 2014, at 12:22 AM, "Alex Harui" wrote:
>>
>> There are functions, but I've seen significant use of XML as an
>>"Object".
>> IMO it is what makes e4x possible: the dot-path lookup as below:
>>
>> Var foo:XML =
>>
>>
>> Trace(foo.is);
>> Trace(foo..a(@name=="test"));
>> Trace(foo..test);
>>
>> But I could be wrong and there is some other way to handle this.
>>
>> -Alex
>>
>>> On 7/3/14 12:51 PM, "Harbs" wrote:
>>>
>>> Why does it need setter/getter? E4X is all functions isn't it?
>>>
>>> Yeah. JSON is generally a better way to go, but some APIs are still XML
>>> and then there's manipulation of XML documents (which I tend to do a
>>>lot
>>> of...)
>>>
On Jul 3, 2014, at 7:53 PM, Alex Harui wrote:
I took a quick look a while back. Required getter/setter support in
the
browser. And then the remaining question: will it perform? It is
similar
to the AMF question. Doable, but may not be faster than switching to
JSON.
-Alex
> On 7/3/14 9:48 AM, "Harbs" wrote:
>
> Has anyone looked into writing a js library to copy the functionality
> of
> E4X?
>
> It seems to me that at least 90% of E4X could be pretty easily
> replicated
> in a js libraryŠ
>
> Besides namespaces, the only thing that seems hard to me is complex
> selectors.
>
>> On Jul 2, 2014, at 7:53 PM, Alex Harui wrote:
>>
>> FWIW, FlexJS is eventually going to need to find a way to warn folks
>> about
>> use of E4X
>
>>>
>>
Re: New Flex to JS project
I think this syntax is just sugar for more verbose function calls like
trace(foo.children("is"))
but the terse syntax is much nicer.
- Gordon
Sent from my iPad
> On Jul 4, 2014, at 12:22 AM, "Alex Harui" wrote:
>
> There are functions, but I've seen significant use of XML as an "Object".
> IMO it is what makes e4x possible: the dot-path lookup as below:
>
> Var foo:XML =
>
>
> Trace(foo.is);
> Trace(foo..a(@name=="test"));
> Trace(foo..test);
>
> But I could be wrong and there is some other way to handle this.
>
> -Alex
>
>> On 7/3/14 12:51 PM, "Harbs" wrote:
>>
>> Why does it need setter/getter? E4X is all functions isn't it?
>>
>> Yeah. JSON is generally a better way to go, but some APIs are still XML
>> and then there's manipulation of XML documents (which I tend to do a lot
>> of...)
>>
>>> On Jul 3, 2014, at 7:53 PM, Alex Harui wrote:
>>>
>>> I took a quick look a while back. Required getter/setter support in the
>>> browser. And then the remaining question: will it perform? It is
>>> similar
>>> to the AMF question. Doable, but may not be faster than switching to
>>> JSON.
>>>
>>> -Alex
>>>
On 7/3/14 9:48 AM, "Harbs" wrote:
Has anyone looked into writing a js library to copy the functionality
of
E4X?
It seems to me that at least 90% of E4X could be pretty easily
replicated
in a js libraryŠ
Besides namespaces, the only thing that seems hard to me is complex
selectors.
> On Jul 2, 2014, at 7:53 PM, Alex Harui wrote:
>
> FWIW, FlexJS is eventually going to need to find a way to warn folks
> about
> use of E4X
>>>
>>
>
Re: New Flex to JS project
There are functions, but I've seen significant use of XML as an "Object". IMO it is what makes e4x possible: the dot-path lookup as below: Var foo:XML = Trace(foo.is); Trace(foo..a(@name=="test")); Trace(foo..test); But I could be wrong and there is some other way to handle this. -Alex On 7/3/14 12:51 PM, "Harbs" wrote: >Why does it need setter/getter? E4X is all functions isn't it? > >Yeah. JSON is generally a better way to go, but some APIs are still XML >and then there's manipulation of XML documents (which I tend to do a lot >of...) > >On Jul 3, 2014, at 7:53 PM, Alex Harui wrote: > >> I took a quick look a while back. Required getter/setter support in the >> browser. And then the remaining question: will it perform? It is >>similar >> to the AMF question. Doable, but may not be faster than switching to >>JSON. >> >> -Alex >> >> On 7/3/14 9:48 AM, "Harbs" wrote: >> >>> Has anyone looked into writing a js library to copy the functionality >>>of >>> E4X? >>> >>> It seems to me that at least 90% of E4X could be pretty easily >>>replicated >>> in a js libraryŠ >>> >>> Besides namespaces, the only thing that seems hard to me is complex >>> selectors. >>> >>> On Jul 2, 2014, at 7:53 PM, Alex Harui wrote: >>> FWIW, FlexJS is eventually going to need to find a way to warn folks about use of E4X >>> >> >
Re: New Flex to JS project
Why does it need setter/getter? E4X is all functions isn’t it? Yeah. JSON is generally a better way to go, but some APIs are still XML and then there’s manipulation of XML documents (which I tend to do a lot of…) On Jul 3, 2014, at 7:53 PM, Alex Harui wrote: > I took a quick look a while back. Required getter/setter support in the > browser. And then the remaining question: will it perform? It is similar > to the AMF question. Doable, but may not be faster than switching to JSON. > > -Alex > > On 7/3/14 9:48 AM, "Harbs" wrote: > >> Has anyone looked into writing a js library to copy the functionality of >> E4X? >> >> It seems to me that at least 90% of E4X could be pretty easily replicated >> in a js libraryŠ >> >> Besides namespaces, the only thing that seems hard to me is complex >> selectors. >> >> On Jul 2, 2014, at 7:53 PM, Alex Harui wrote: >> >>> FWIW, FlexJS is eventually going to need to find a way to warn folks >>> about >>> use of E4X >> >
Re: New Flex to JS project
I took a quick look a while back. Required getter/setter support in the browser. And then the remaining question: will it perform? It is similar to the AMF question. Doable, but may not be faster than switching to JSON. -Alex On 7/3/14 9:48 AM, "Harbs" wrote: >Has anyone looked into writing a js library to copy the functionality of >E4X? > >It seems to me that at least 90% of E4X could be pretty easily replicated >in a js libraryŠ > >Besides namespaces, the only thing that seems hard to me is complex >selectors. > >On Jul 2, 2014, at 7:53 PM, Alex Harui wrote: > >> FWIW, FlexJS is eventually going to need to find a way to warn folks >>about >> use of E4X >
Re: New Flex to JS project
Has anyone looked into writing a js library to copy the functionality of E4X? It seems to me that at least 90% of E4X could be pretty easily replicated in a js library… Besides namespaces, the only thing that seems hard to me is complex selectors. On Jul 2, 2014, at 7:53 PM, Alex Harui wrote: > FWIW, FlexJS is eventually going to need to find a way to warn folks about > use of E4X
Re: New Flex to JS project
I think it has to be in public. This is open development. I'm hoping you will save me time by doing so. If we are doing something we shouldn't we should correct it now otherwise we'll waste time and energy doing more work in that direction only to find out that customers have the same feedback. Not that all of your feedback is guaranteed to be addressed: there's always a chance that what you don't like is philosophical rather than technical. That's why there are dozens of JS frameworks already and why you want to try a different approach. -Alex On 7/3/14 12:00 AM, "Erik de Bruin" wrote: >You want to hear that in public, or do you want to take this off list? > >EdB > > > > >On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui wrote: > >> >> >> >> >I've been doing that as well for the last couple of years. I spent >>most of >> >my time getting FlexJS off the ground. But I don't agree with some of >>the >> >basic assumptions and choices that FlexJS has made. I said little or >> >nothing about it to give FlexJS a proper head start and to keep you and >> >Peter going. But now that I have re-evaluated what the project means to >> >me, >> >and what I would like to spend my time on when contributing, and I >>have to >> >give my take on Flex to JS a try. >> I'd love to hear your thoughts on what you don't agree with regarding >> FlexJS. >> >> -Alex >> >> > > >-- >Ix Multimedia Software > >Jan Luykenstraat 27 >3521 VB Utrecht > >T. 06-51952295 >I. www.ixsoftware.nl
Re: New Flex to JS project
On 7/3/14 6:10 AM, "Igor Costa" wrote: >@Alex > >I will push to my white_board for sure it's already in Apache license. >The >good thing about polymer it's event handling that got my attention and >'design in mind' like we had with Flex Spark components. > >That's very cool about cordova, jquery and createJS. It's available >anywhere? It is in the releases and examples. This is all early alpha stuff so feel free to add your polymer stuff in the same way. Grepping for Cordove, jquery or createJS should show you the examples and files that go in the SWC although soon we will break them out into their own swcs. -Alex
Re: New Flex to JS project
@Alex I will push to my white_board for sure it's already in Apache license. The good thing about polymer it's event handling that got my attention and 'design in mind' like we had with Flex Spark components. That's very cool about cordova, jquery and createJS. It's available anywhere? Best Igor Costa www.igorcosta.com www.igorcosta.org On Thu, Jul 3, 2014 at 4:00 AM, Erik de Bruin wrote: > You want to hear that in public, or do you want to take this off list? > > EdB > > > > > On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui wrote: > > > > > > > > > >I've been doing that as well for the last couple of years. I spent most > of > > >my time getting FlexJS off the ground. But I don't agree with some of > the > > >basic assumptions and choices that FlexJS has made. I said little or > > >nothing about it to give FlexJS a proper head start and to keep you and > > >Peter going. But now that I have re-evaluated what the project means to > > >me, > > >and what I would like to spend my time on when contributing, and I have > to > > >give my take on Flex to JS a try. > > I'd love to hear your thoughts on what you don't agree with regarding > > FlexJS. > > > > -Alex > > > > > > > -- > Ix Multimedia Software > > Jan Luykenstraat 27 > 3521 VB Utrecht > > T. 06-51952295 > I. www.ixsoftware.nl >
Re: New Flex to JS project
You want to hear that in public, or do you want to take this off list? EdB On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui wrote: > > > > >I've been doing that as well for the last couple of years. I spent most of > >my time getting FlexJS off the ground. But I don't agree with some of the > >basic assumptions and choices that FlexJS has made. I said little or > >nothing about it to give FlexJS a proper head start and to keep you and > >Peter going. But now that I have re-evaluated what the project means to > >me, > >and what I would like to spend my time on when contributing, and I have to > >give my take on Flex to JS a try. > I'd love to hear your thoughts on what you don't agree with regarding > FlexJS. > > -Alex > > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: New Flex to JS project
Hi Igor, Can you donate some of your FlexJS/Polymer code to Apache? We've already got the beginnings of Cordova, Jquery and CreateJS. Polymer sounds like a good addition. Thanks, -Alex On 7/2/14 1:31 PM, "Igor Costa" wrote: >Erik > >Right now I'm on a stage of prove of concept using FlexJS and using >Polymer >as the output template. I made with success at least with a simple button. >Polymer has similar architecture as Flex. > >Is there a way I can share each other code? I'm not so familiar with >vanila sdk. > > >Best Regards > > >Igor Costa >www.igorcosta.com >www.igorcosta.org > > >On Wed, Jul 2, 2014 at 4:59 PM, Nicholas Kwiatkowski >wrote: > >> It's pretty much one command. The same one you use to keep develop >>current >> with your branch :) >> >> -Nick >> >> >> On Wed, Jul 2, 2014 at 11:20 AM, Erik de Bruin >>wrote: >> >> > On git: let's assume I work on these branches for 6 months (while >>keeping >> > them up to date with develop). How much of a hassle will it be to >>merge >> > them back into their respective 'develop' branches? >> > >> > EdB >> > >> > >> > >> > On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala < >> bigosma...@gmail.com >> > > >> > wrote: >> > >> > > On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz < >> > christofer.d...@c-ware.de >> > > > >> > > wrote: >> > > >> > > > You don't loose the history when rebasing ... you sort of >>serialize >> it. >> > > Ok >> > > > the order of commits is messed up, but I never really care about >> this. >> > > > It might look less interesting in a GIT visualization tool where >>you >> > > could >> > > > see tons of different branches and merges, but it should be a lot >> > easier >> > > to >> > > > maintain, as a serial history is definiely the one that causes the >> > least >> > > > trouble ;-) >> > > > >> > > > In IntelliJ I usually set my "update" operation to "Rebase" using >> > "Stash" >> > > > and have never really had any problems. One click on "Update SCM" >> and I >> > > > still work on my featrue branch, but pull in all changes from >>develop >> > or >> > > > whatever branch I branched from. When it comes to commit, the >>commit >> > > itself >> > > > should be a fast-forward commit. >> > > > >> > > > But I guess there are several flavours here ... depending on the >>guy >> > you >> > > > ask or listen too, a different way will probably be recommended. I >> > guess >> > > > manually merging changes from develop to the feature branch is as >> valid >> > > as >> > > > rebasing, but I think rebasing is easier and causes less trouble, >>but >> > you >> > > > loose the "real-order" of commits (Which I don't really care >>about). >> > > > >> > > > Chris >> > > > >> > > >> > > I will let Erik decide if he wants to rebase or merge. My >> recommendation >> > > is that, since it is a feature branch, it will be useful to retain >>the >> > > commit history intact. So, merge makes sense. >> > > >> > > If Erik does not want to keep the commit history intact, rebase will >> just >> > > work fine. >> > > >> > > Thanks, >> > > Om >> > > >> > > >> > > > >> > > > >> > > > >> > > > >> > > > Von: omup...@gmail.com im Auftrag von >>OmPrakash >> > > > Muppirala >> > > > Gesendet: Mittwoch, 2. Juli 2014 10:25 >> > > > An: dev@flex.apache.org >> > > > Betreff: Re: New Flex to JS project >> > > > >> > > > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin >> > > wrote: >> > > > >> > > > > Ok, just checking: >> > > > > >> > > > > I create a local branch, let's call it 'vf2js', off >> > 'origin/develop'. I >> > >
Re: New Flex to JS project
>I've been doing that as well for the last couple of years. I spent most of >my time getting FlexJS off the ground. But I don't agree with some of the >basic assumptions and choices that FlexJS has made. I said little or >nothing about it to give FlexJS a proper head start and to keep you and >Peter going. But now that I have re-evaluated what the project means to >me, >and what I would like to spend my time on when contributing, and I have to >give my take on Flex to JS a try. I'd love to hear your thoughts on what you don't agree with regarding FlexJS. -Alex
Re: New Flex to JS project
Erik Right now I'm on a stage of prove of concept using FlexJS and using Polymer as the output template. I made with success at least with a simple button. Polymer has similar architecture as Flex. Is there a way I can share each other code? I'm not so familiar with vanila sdk. Best Regards Igor Costa www.igorcosta.com www.igorcosta.org On Wed, Jul 2, 2014 at 4:59 PM, Nicholas Kwiatkowski wrote: > It's pretty much one command. The same one you use to keep develop current > with your branch :) > > -Nick > > > On Wed, Jul 2, 2014 at 11:20 AM, Erik de Bruin wrote: > > > On git: let's assume I work on these branches for 6 months (while keeping > > them up to date with develop). How much of a hassle will it be to merge > > them back into their respective 'develop' branches? > > > > EdB > > > > > > > > On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala < > bigosma...@gmail.com > > > > > wrote: > > > > > On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz < > > christofer.d...@c-ware.de > > > > > > > wrote: > > > > > > > You don't loose the history when rebasing ... you sort of serialize > it. > > > Ok > > > > the order of commits is messed up, but I never really care about > this. > > > > It might look less interesting in a GIT visualization tool where you > > > could > > > > see tons of different branches and merges, but it should be a lot > > easier > > > to > > > > maintain, as a serial history is definiely the one that causes the > > least > > > > trouble ;-) > > > > > > > > In IntelliJ I usually set my "update" operation to "Rebase" using > > "Stash" > > > > and have never really had any problems. One click on "Update SCM" > and I > > > > still work on my featrue branch, but pull in all changes from develop > > or > > > > whatever branch I branched from. When it comes to commit, the commit > > > itself > > > > should be a fast-forward commit. > > > > > > > > But I guess there are several flavours here ... depending on the guy > > you > > > > ask or listen too, a different way will probably be recommended. I > > guess > > > > manually merging changes from develop to the feature branch is as > valid > > > as > > > > rebasing, but I think rebasing is easier and causes less trouble, but > > you > > > > loose the "real-order" of commits (Which I don't really care about). > > > > > > > > Chris > > > > > > > > > > I will let Erik decide if he wants to rebase or merge. My > recommendation > > > is that, since it is a feature branch, it will be useful to retain the > > > commit history intact. So, merge makes sense. > > > > > > If Erik does not want to keep the commit history intact, rebase will > just > > > work fine. > > > > > > Thanks, > > > Om > > > > > > > > > > > > > > > > > > > > > > > > > > Von: omup...@gmail.com im Auftrag von OmPrakash > > > > Muppirala > > > > Gesendet: Mittwoch, 2. Juli 2014 10:25 > > > > An: dev@flex.apache.org > > > > Betreff: Re: New Flex to JS project > > > > > > > > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin > > > wrote: > > > > > > > > > Ok, just checking: > > > > > > > > > > I create a local branch, let's call it 'vf2js', off > > 'origin/develop'. I > > > > > select this as my active branch. > > > > > > > > > > > > So far so good. > > > > > > > > > > > > > If I then 'rebase', all changes that have > > > > > been made to 'origin/develop' will be pulled into my local branch? > So > > > > far, > > > > > so good. > > > > > > > > > > > > Rebase at this point is not required. The code from origin/develop > is > > > > already in the 'vf2js' branch. You will need to 'merge' from > > > > origin/develop into vf2js once in a while to make sure that you are > in > > > sync > > > > with whats happening with origin/develop.
Re: New Flex to JS project
It's pretty much one command. The same one you use to keep develop current with your branch :) -Nick On Wed, Jul 2, 2014 at 11:20 AM, Erik de Bruin wrote: > On git: let's assume I work on these branches for 6 months (while keeping > them up to date with develop). How much of a hassle will it be to merge > them back into their respective 'develop' branches? > > EdB > > > > On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala > > wrote: > > > On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz < > christofer.d...@c-ware.de > > > > > wrote: > > > > > You don't loose the history when rebasing ... you sort of serialize it. > > Ok > > > the order of commits is messed up, but I never really care about this. > > > It might look less interesting in a GIT visualization tool where you > > could > > > see tons of different branches and merges, but it should be a lot > easier > > to > > > maintain, as a serial history is definiely the one that causes the > least > > > trouble ;-) > > > > > > In IntelliJ I usually set my "update" operation to "Rebase" using > "Stash" > > > and have never really had any problems. One click on "Update SCM" and I > > > still work on my featrue branch, but pull in all changes from develop > or > > > whatever branch I branched from. When it comes to commit, the commit > > itself > > > should be a fast-forward commit. > > > > > > But I guess there are several flavours here ... depending on the guy > you > > > ask or listen too, a different way will probably be recommended. I > guess > > > manually merging changes from develop to the feature branch is as valid > > as > > > rebasing, but I think rebasing is easier and causes less trouble, but > you > > > loose the "real-order" of commits (Which I don't really care about). > > > > > > Chris > > > > > > > I will let Erik decide if he wants to rebase or merge. My recommendation > > is that, since it is a feature branch, it will be useful to retain the > > commit history intact. So, merge makes sense. > > > > If Erik does not want to keep the commit history intact, rebase will just > > work fine. > > > > Thanks, > > Om > > > > > > > > > > > > > > > > > > > Von: omup...@gmail.com im Auftrag von OmPrakash > > > Muppirala > > > Gesendet: Mittwoch, 2. Juli 2014 10:25 > > > An: dev@flex.apache.org > > > Betreff: Re: New Flex to JS project > > > > > > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin > > wrote: > > > > > > > Ok, just checking: > > > > > > > > I create a local branch, let's call it 'vf2js', off > 'origin/develop'. I > > > > select this as my active branch. > > > > > > > > > So far so good. > > > > > > > > > > If I then 'rebase', all changes that have > > > > been made to 'origin/develop' will be pulled into my local branch? So > > > far, > > > > so good. > > > > > > > > > Rebase at this point is not required. The code from origin/develop is > > > already in the 'vf2js' branch. You will need to 'merge' from > > > origin/develop into vf2js once in a while to make sure that you are in > > sync > > > with whats happening with origin/develop. When you are done with the > > > feature, you just 'merge' vf2js into develop. If the history of the > > > 'vf2js' branch is not important, then you use the rebase option. > > > > > > > > > > But now I want the world to see what's in my local vf2js branch, > > > > so I 'publish' it. Is keeping the remote copy of my local branch up > to > > > date > > > > just a question of 'pushing' all commits to that remote branch? > > > > > > > > > Yes, that is correct. > > > > > > > > > > Will > > > > changes that come from the remote 'develop' via my local 'vf2js' also > > in > > > > the remote 'vf2js' that way? > > > > > > > > > > Cannot compute. Can you rephrase the question? > > > > > > > > > > > > > > Thanks, > > >
Re: New Flex to JS project
> > The namespace and MVC in in the new AS/JS framework but I don't think > there is anything in the current FlexJS setup what would block you from > swapping in a set of SWCs that use the mx and/or spark NS. > No, I'm actually swapping OUT the mx and/or Spark NS from the regular SDK. VF2JS projects are regular Flex projects, using the 4.13.0 SDK or whatever is current at the time. User code normally, with the regular Flex namespaces. They use the normal workflow to debug and publish their projects to SWF. Only when the chose to publish to JS the fun starts. I create a copy of their regular MX/Spark project, swap out the 's' and 'mx' namespaces for the new ones I created and feed that temporary copy to FalconJX. Since it uses the new namespaces, the compiler will compile against the shim components I created in the accompanying projects. That way if there are APIs used in the regular Flex project that are not supported in the JavaScript framework - and therefor not present in the shims- the compiler will warn the user and ignore that API. >On the JS side, > >no MXML as data, just objects/components and much more integration with > >the > >GC Library (createDom, enterDocument and Dispose for life cycle of any > >component; event handling through current API instead of deprecated stuff; > >ES5 and 6 etc.). > Other than MXML as data, I don't think there is anything about current > FlexJS that would prevent you from building out a JS library that uses > more of GC as you want. I hope there will be libraries that live on top > of Jquery, Angular, etc > Trust me, I build a lot of the FalconJX code that translates AS/MXML to JS, as well as some of the core functionality of the JS framework and there is a lot of room for improvement in there. > I'm just looking for ways to avoid us doing some things twice. > I've been doing that as well for the last couple of years. I spent most of my time getting FlexJS off the ground. But I don't agree with some of the basic assumptions and choices that FlexJS has made. I said little or nothing about it to give FlexJS a proper head start and to keep you and Peter going. But now that I have re-evaluated what the project means to me, and what I would like to spend my time on when contributing, and I have to give my take on Flex to JS a try. I will keep supporting FlexJS where it concerns changes/enhancements that need to be made to FalconJX, of course. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: New Flex to JS project
On 7/2/14 10:05 AM, "Erik de Bruin" wrote: >> >> I'm still trying to figure out why your Vanilla implementation, given it >> is going to have custom swcs, isn't just another FlexJS library. I >>think >> the main difference is in the reporting of missing mx/spark APIs. Is >> there more? > > >No, there is less. No special namespaces or MVC for the Flex side, just >the >SDK as we know and love it, unchanged as far as the user is concerned - >any >project that uses MX and/or Spark will cross compile to JS. The namespace and MVC in in the new AS/JS framework but I don't think there is anything in the current FlexJS setup what would block you from swapping in a set of SWCs that use the mx and/or spark NS. >On the JS side, >no MXML as data, just objects/components and much more integration with >the >GC Library (createDom, enterDocument and Dispose for life cycle of any >component; event handling through current API instead of deprecated stuff; >ES5 and 6 etc.). Other than MXML as data, I don't think there is anything about current FlexJS that would prevent you from building out a JS library that uses more of GC as you want. I hope there will be libraries that live on top of Jquery, Angular, etc. I'm just looking for ways to avoid us doing some things twice. -Alex
Re: New Flex to JS project
> > I'm still trying to figure out why your Vanilla implementation, given it > is going to have custom swcs, isn't just another FlexJS library. I think > the main difference is in the reporting of missing mx/spark APIs. Is > there more? No, there is less. No special namespaces or MVC for the Flex side, just the SDK as we know and love it, unchanged as far as the user is concerned - any project that uses MX and/or Spark will cross compile to JS. On the JS side, no MXML as data, just objects/components and much more integration with the GC Library (createDom, enterDocument and Dispose for life cycle of any component; event handling through current API instead of deprecated stuff; ES5 and 6 etc.). EdB > -Alex > > On 7/2/14 8:42 AM, "Erik de Bruin" wrote: > > >> > >> Sounds interesting. Is there any way to get more information on what > >> kinds of changes are going to be made? More comments in-line. > >> > > > >I'm basically making this up as I go along, but... The workflow for > >producing SWFs doesn't change at all. Hence 'Vanilla Flex'. If someone > >wants to publish his normal Flex project to JavaScript, he uses an > >External > >Tool to launch FalconJX with the vanilla Flex project as input. In order > >to > >give the user feedback on which components and properties on components > >are > >supported by the JS framework, the Flex SDK gets two new namespaces with > >accompanying shim components. The shims will contain only the public APIs > >supported by the JS framework. These namespaces will be 'swapped in' by > >FalconJX during a publish to JS. I plan to have the compiler produce a > >nice > >full AST or give the user feedback about stuff it cannot 'translate' > >because the shim components don't allow complete compilation due to the > >use > >of unsupported properties. From the AST, I plan to use all I learned > >writing FalconJX for FlexJS and using the GC Tools daily for over a year > >now, and produce very GCC friendly JavaScript. > > > >>1) two new namespaces and accompanying projects in the main Flex SDK: > >> >vf2js_mx and vf2js_s. These namespaces will contain shim objects for > >>(you > >> >guessed it) MX and Spark components. > >> Just wondering after seeing all the branch/merge discussion: are you > >>sure > >> you can't auto-generate the shims via a custom back-end for FalconJX? > >>It > >> could suck in your JS files as well if that helps to compute the shim. > >> Then you may not need to branch/merge at all and just be a separate swc > >> project or two (or three). > >> > > > >I have two new projects in 'sdk/frameworks/projects', and I've changed the > >supporting files to build them with the SDK. There are relatively few > >changes in the SDK, apart from those new swc projects. I was told to > >branch, and I did because I'm not sure if the changes I made to the > >supporting config files are correct. When I have a working prototype, and > >my branched SDK passes all Mustella tests, I'll start asking permission to > >merge it back into 'develop'. The new stuff doesn't touch any of the > >existing stuff, so I'm not expecting any problems on that front. > > > >>2) two new code paths in FalconJX: one for AS and one for MXML > >> If the changes going in here are not going to interfere with FlexJS, I > >> don't see why you need to branch now. FlexJS is in alpha, so having > >>other > >> alpha/prototype code in its release shouldn't be a killer. > > > > > >I decided to branch this project because I expect not to be able to leave > >the FalconJX in a functioning state after each and every commit. I don't > >want to bother anyone with my half backed experiments, let alone break the > >nightly builds. > > > > > >> >B - In order for this to work, FalconJX needs to be part of the regular > >> >SDK > >> >distribution. Folks who did this on the FlexJS overlay: what does it > >>take > >> >to make FalconJX part of the SDK? > >> > >> I'm not quite sure what this means. Why can't it be an overlay? If > >>Chris > >> is right and you want FB integration such that building the FB project > >> runs FalconJX, that part is in the flex-oem-compiler project. You > >>should > >> be able to follow what I did in git history and get an idea of what you > >> need to change, but there is one possible gotcha: FB runs in Java 6 > >>and I > >> believe GCC required Java 7. I'm not sure if there is a way to have > >>FB's > >> Java 6 call into GCC without recompiling GCC to Java 6 (which is an > >>option > >> I think). > >> > > > >The idea is to change nothing to the FB workflow, just add an External > >Tool > >option to publish an existing project to JavaScript. I hope, since the aim > >is to have 'vanilla' SWF development, that we can make this project part > >of > >the regular SDK, not a separate release. Also, I figure that another > >subproject that needs a release cycle etc. might very well break Apache > >Flex due to release overload. > > > >But we're not there yet, so, first things first: a nice proo
Re: New Flex to JS project
That's kind of what I would've guessed. Still makes me wonder about auto generating the shims from your JS source. FWIW, FlexJS is eventually going to need to find a way to warn folks about use of E4X and a few other things in a FlexJS app. I was going to try to inject that intelligence into Falcon since in FlexJS that's where the initial compilation runs. Hopefully we can use the same implementation for that. It might be better to warn folks while they are editing/compiling vs when they run the external tool. I'm still trying to figure out why your Vanilla implementation, given it is going to have custom swcs, isn't just another FlexJS library. I think the main difference is in the reporting of missing mx/spark APIs. Is there more? -Alex On 7/2/14 8:42 AM, "Erik de Bruin" wrote: >> >> Sounds interesting. Is there any way to get more information on what >> kinds of changes are going to be made? More comments in-line. >> > >I'm basically making this up as I go along, but... The workflow for >producing SWFs doesn't change at all. Hence 'Vanilla Flex'. If someone >wants to publish his normal Flex project to JavaScript, he uses an >External >Tool to launch FalconJX with the vanilla Flex project as input. In order >to >give the user feedback on which components and properties on components >are >supported by the JS framework, the Flex SDK gets two new namespaces with >accompanying shim components. The shims will contain only the public APIs >supported by the JS framework. These namespaces will be 'swapped in' by >FalconJX during a publish to JS. I plan to have the compiler produce a >nice >full AST or give the user feedback about stuff it cannot 'translate' >because the shim components don't allow complete compilation due to the >use >of unsupported properties. From the AST, I plan to use all I learned >writing FalconJX for FlexJS and using the GC Tools daily for over a year >now, and produce very GCC friendly JavaScript. > >>1) two new namespaces and accompanying projects in the main Flex SDK: >> >vf2js_mx and vf2js_s. These namespaces will contain shim objects for >>(you >> >guessed it) MX and Spark components. >> Just wondering after seeing all the branch/merge discussion: are you >>sure >> you can't auto-generate the shims via a custom back-end for FalconJX? >>It >> could suck in your JS files as well if that helps to compute the shim. >> Then you may not need to branch/merge at all and just be a separate swc >> project or two (or three). >> > >I have two new projects in 'sdk/frameworks/projects', and I've changed the >supporting files to build them with the SDK. There are relatively few >changes in the SDK, apart from those new swc projects. I was told to >branch, and I did because I'm not sure if the changes I made to the >supporting config files are correct. When I have a working prototype, and >my branched SDK passes all Mustella tests, I'll start asking permission to >merge it back into 'develop'. The new stuff doesn't touch any of the >existing stuff, so I'm not expecting any problems on that front. > >>2) two new code paths in FalconJX: one for AS and one for MXML >> If the changes going in here are not going to interfere with FlexJS, I >> don't see why you need to branch now. FlexJS is in alpha, so having >>other >> alpha/prototype code in its release shouldn't be a killer. > > >I decided to branch this project because I expect not to be able to leave >the FalconJX in a functioning state after each and every commit. I don't >want to bother anyone with my half backed experiments, let alone break the >nightly builds. > > >> >B - In order for this to work, FalconJX needs to be part of the regular >> >SDK >> >distribution. Folks who did this on the FlexJS overlay: what does it >>take >> >to make FalconJX part of the SDK? >> >> I'm not quite sure what this means. Why can't it be an overlay? If >>Chris >> is right and you want FB integration such that building the FB project >> runs FalconJX, that part is in the flex-oem-compiler project. You >>should >> be able to follow what I did in git history and get an idea of what you >> need to change, but there is one possible gotcha: FB runs in Java 6 >>and I >> believe GCC required Java 7. I'm not sure if there is a way to have >>FB's >> Java 6 call into GCC without recompiling GCC to Java 6 (which is an >>option >> I think). >> > >The idea is to change nothing to the FB workflow, just add an External >Tool >option to publish an existing project to JavaScript. I hope, since the aim >is to have 'vanilla' SWF development, that we can make this project part >of >the regular SDK, not a separate release. Also, I figure that another >subproject that needs a release cycle etc. might very well break Apache >Flex due to release overload. > >But we're not there yet, so, first things first: a nice proof of concept >and some thinking on how we can best make this work from a user's point of >view. > >Thanks, > >EdB > > > >-- >Ix Multimedia Software > >J
Re: New Flex to JS project
On Jul 2, 2014 8:21 AM, "Erik de Bruin" wrote: > > On git: let's assume I work on these branches for 6 months (while keeping > them up to date with develop). How much of a hassle will it be to merge > them back into their respective 'develop' branches? That depends on what files you touch and what others touch in develop. If there are a lot of conflicts, merging after 6 months could get hairy. But then, if you keep merging develop into your branch once in a while, you can keep resolving the small set of potential conflicts as you go on. In then end you will probably have no conflicts to resolve. You can merge in a matter of minutes. Thanks, Om > > EdB > > > > On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala > wrote: > > > On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz < christofer.d...@c-ware.de > > > > > wrote: > > > > > You don't loose the history when rebasing ... you sort of serialize it. > > Ok > > > the order of commits is messed up, but I never really care about this. > > > It might look less interesting in a GIT visualization tool where you > > could > > > see tons of different branches and merges, but it should be a lot easier > > to > > > maintain, as a serial history is definiely the one that causes the least > > > trouble ;-) > > > > > > In IntelliJ I usually set my "update" operation to "Rebase" using "Stash" > > > and have never really had any problems. One click on "Update SCM" and I > > > still work on my featrue branch, but pull in all changes from develop or > > > whatever branch I branched from. When it comes to commit, the commit > > itself > > > should be a fast-forward commit. > > > > > > But I guess there are several flavours here ... depending on the guy you > > > ask or listen too, a different way will probably be recommended. I guess > > > manually merging changes from develop to the feature branch is as valid > > as > > > rebasing, but I think rebasing is easier and causes less trouble, but you > > > loose the "real-order" of commits (Which I don't really care about). > > > > > > Chris > > > > > > > I will let Erik decide if he wants to rebase or merge. My recommendation > > is that, since it is a feature branch, it will be useful to retain the > > commit history intact. So, merge makes sense. > > > > If Erik does not want to keep the commit history intact, rebase will just > > work fine. > > > > Thanks, > > Om > > > > > > > > > > > > > > > > > > > Von: omup...@gmail.com im Auftrag von OmPrakash > > > Muppirala > > > Gesendet: Mittwoch, 2. Juli 2014 10:25 > > > An: dev@flex.apache.org > > > Betreff: Re: New Flex to JS project > > > > > > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin > > wrote: > > > > > > > Ok, just checking: > > > > > > > > I create a local branch, let's call it 'vf2js', off 'origin/develop'. I > > > > select this as my active branch. > > > > > > > > > So far so good. > > > > > > > > > > If I then 'rebase', all changes that have > > > > been made to 'origin/develop' will be pulled into my local branch? So > > > far, > > > > so good. > > > > > > > > > Rebase at this point is not required. The code from origin/develop is > > > already in the 'vf2js' branch. You will need to 'merge' from > > > origin/develop into vf2js once in a while to make sure that you are in > > sync > > > with whats happening with origin/develop. When you are done with the > > > feature, you just 'merge' vf2js into develop. If the history of the > > > 'vf2js' branch is not important, then you use the rebase option. > > > > > > > > > > But now I want the world to see what's in my local vf2js branch, > > > > so I 'publish' it. Is keeping the remote copy of my local branch up to > > > date > > > > just a question of 'pushing' all commits to that remote branch? > > > > > > > > > Yes, that is correct. > > > > > > > > > > Will > > > > changes that come from the remote 'develop' via my local 'vf2js' also
Re: New Flex to JS project
> > Sounds interesting. Is there any way to get more information on what > kinds of changes are going to be made? More comments in-line. > I'm basically making this up as I go along, but... The workflow for producing SWFs doesn't change at all. Hence 'Vanilla Flex'. If someone wants to publish his normal Flex project to JavaScript, he uses an External Tool to launch FalconJX with the vanilla Flex project as input. In order to give the user feedback on which components and properties on components are supported by the JS framework, the Flex SDK gets two new namespaces with accompanying shim components. The shims will contain only the public APIs supported by the JS framework. These namespaces will be 'swapped in' by FalconJX during a publish to JS. I plan to have the compiler produce a nice full AST or give the user feedback about stuff it cannot 'translate' because the shim components don't allow complete compilation due to the use of unsupported properties. From the AST, I plan to use all I learned writing FalconJX for FlexJS and using the GC Tools daily for over a year now, and produce very GCC friendly JavaScript. >1) two new namespaces and accompanying projects in the main Flex SDK: > >vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you > >guessed it) MX and Spark components. > Just wondering after seeing all the branch/merge discussion: are you sure > you can't auto-generate the shims via a custom back-end for FalconJX? It > could suck in your JS files as well if that helps to compute the shim. > Then you may not need to branch/merge at all and just be a separate swc > project or two (or three). > I have two new projects in 'sdk/frameworks/projects', and I've changed the supporting files to build them with the SDK. There are relatively few changes in the SDK, apart from those new swc projects. I was told to branch, and I did because I'm not sure if the changes I made to the supporting config files are correct. When I have a working prototype, and my branched SDK passes all Mustella tests, I'll start asking permission to merge it back into 'develop'. The new stuff doesn't touch any of the existing stuff, so I'm not expecting any problems on that front. >2) two new code paths in FalconJX: one for AS and one for MXML > If the changes going in here are not going to interfere with FlexJS, I > don't see why you need to branch now. FlexJS is in alpha, so having other > alpha/prototype code in its release shouldn't be a killer. I decided to branch this project because I expect not to be able to leave the FalconJX in a functioning state after each and every commit. I don't want to bother anyone with my half backed experiments, let alone break the nightly builds. > >B - In order for this to work, FalconJX needs to be part of the regular > >SDK > >distribution. Folks who did this on the FlexJS overlay: what does it take > >to make FalconJX part of the SDK? > > I'm not quite sure what this means. Why can't it be an overlay? If Chris > is right and you want FB integration such that building the FB project > runs FalconJX, that part is in the flex-oem-compiler project. You should > be able to follow what I did in git history and get an idea of what you > need to change, but there is one possible gotcha: FB runs in Java 6 and I > believe GCC required Java 7. I'm not sure if there is a way to have FB's > Java 6 call into GCC without recompiling GCC to Java 6 (which is an option > I think). > The idea is to change nothing to the FB workflow, just add an External Tool option to publish an existing project to JavaScript. I hope, since the aim is to have 'vanilla' SWF development, that we can make this project part of the regular SDK, not a separate release. Also, I figure that another subproject that needs a release cycle etc. might very well break Apache Flex due to release overload. But we're not there yet, so, first things first: a nice proof of concept and some thinking on how we can best make this work from a user's point of view. Thanks, EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: New Flex to JS project
On git: let's assume I work on these branches for 6 months (while keeping them up to date with develop). How much of a hassle will it be to merge them back into their respective 'develop' branches? EdB On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala wrote: > On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz > > wrote: > > > You don't loose the history when rebasing ... you sort of serialize it. > Ok > > the order of commits is messed up, but I never really care about this. > > It might look less interesting in a GIT visualization tool where you > could > > see tons of different branches and merges, but it should be a lot easier > to > > maintain, as a serial history is definiely the one that causes the least > > trouble ;-) > > > > In IntelliJ I usually set my "update" operation to "Rebase" using "Stash" > > and have never really had any problems. One click on "Update SCM" and I > > still work on my featrue branch, but pull in all changes from develop or > > whatever branch I branched from. When it comes to commit, the commit > itself > > should be a fast-forward commit. > > > > But I guess there are several flavours here ... depending on the guy you > > ask or listen too, a different way will probably be recommended. I guess > > manually merging changes from develop to the feature branch is as valid > as > > rebasing, but I think rebasing is easier and causes less trouble, but you > > loose the "real-order" of commits (Which I don't really care about). > > > > Chris > > > > I will let Erik decide if he wants to rebase or merge. My recommendation > is that, since it is a feature branch, it will be useful to retain the > commit history intact. So, merge makes sense. > > If Erik does not want to keep the commit history intact, rebase will just > work fine. > > Thanks, > Om > > > > > > > > > > > > Von: omup...@gmail.com im Auftrag von OmPrakash > > Muppirala > > Gesendet: Mittwoch, 2. Juli 2014 10:25 > > An: dev@flex.apache.org > > Betreff: Re: New Flex to JS project > > > > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin > wrote: > > > > > Ok, just checking: > > > > > > I create a local branch, let's call it 'vf2js', off 'origin/develop'. I > > > select this as my active branch. > > > > > > So far so good. > > > > > > > If I then 'rebase', all changes that have > > > been made to 'origin/develop' will be pulled into my local branch? So > > far, > > > so good. > > > > > > Rebase at this point is not required. The code from origin/develop is > > already in the 'vf2js' branch. You will need to 'merge' from > > origin/develop into vf2js once in a while to make sure that you are in > sync > > with whats happening with origin/develop. When you are done with the > > feature, you just 'merge' vf2js into develop. If the history of the > > 'vf2js' branch is not important, then you use the rebase option. > > > > > > > But now I want the world to see what's in my local vf2js branch, > > > so I 'publish' it. Is keeping the remote copy of my local branch up to > > date > > > just a question of 'pushing' all commits to that remote branch? > > > > > > Yes, that is correct. > > > > > > > Will > > > changes that come from the remote 'develop' via my local 'vf2js' also > in > > > the remote 'vf2js' that way? > > > > > > > Cannot compute. Can you rephrase the question? > > > > > > > > > > Thanks, > > > > > > EdB > > > > > > > > > > > > On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz < > > christofer.d...@c-ware.de > > > > > > > wrote: > > > > > > > No effort at all ... that's what GIT rebase is for. > > > > > > > > You can think of this sort of an automated "Create-Patch, Revert, > > Update, > > > > Apply Patch" ... if all goes well, it's just this one command, if > there > > > are > > > > conflicts, you get the usual conflict editor you would get anyway if > > you > > > > created conflicts on develop. > > > > > > > > Chris > > > > > > > > &g
Re: New Flex to JS project
Sounds interesting. Is there any way to get more information on what kinds of changes are going to be made? More comments in-line. On 7/2/14 12:33 AM, "Erik de Bruin" wrote: >Hi, > >I'm working on creating a way to publish vanilla Flex SDK projects to >JavaScript on latest gen browsers. This project consists of several sub >projects, and I'm wondering what is the best way forward with regard to >contributing them: > >1) two new namespaces and accompanying projects in the main Flex SDK: >vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you >guessed it) MX and Spark components. Just wondering after seeing all the branch/merge discussion: are you sure you can't auto-generate the shims via a custom back-end for FalconJX? It could suck in your JS files as well if that helps to compute the shim. Then you may not need to branch/merge at all and just be a separate swc project or two (or three). > >2) two new code paths in FalconJX: one for AS and one for MXML If the changes going in here are not going to interfere with FlexJS, I don't see why you need to branch now. FlexJS is in alpha, so having other alpha/prototype code in its release shouldn't be a killer. > >3) a new JavaScript library for the components and shims for AS classes > >4) a testing framework for the JS components, loosely based on Marmotinni > >Questions: > >A - I would very much like to work in the 'develop' branches of the >projects involved, but especially on the part of '1)' I'm not sure if I >did >it right. All tests I can think of seem to pass, but maybe someone has the >time to do a code review on a branch that I can publish? > >B - In order for this to work, FalconJX needs to be part of the regular >SDK >distribution. Folks who did this on the FlexJS overlay: what does it take >to make FalconJX part of the SDK? I'm not quite sure what this means. Why can't it be an overlay? If Chris is right and you want FB integration such that building the FB project runs FalconJX, that part is in the flex-oem-compiler project. You should be able to follow what I did in git history and get an idea of what you need to change, but there is one possible gotcha: FB runs in Java 6 and I believe GCC required Java 7. I'm not sure if there is a way to have FB's Java 6 call into GCC without recompiling GCC to Java 6 (which is an option I think). HTH, -Alex
Re: New Flex to JS project
Nobody will ever have to use these namespaces in their projects. The compiler replaces the 's' and 'mx' namespaces with 'vf2js_mx' and 'vf2js_s' in a temp copy of the project which is only used published to JS before being deleted again. The shim components in these namespaces are there only to get feedback from the compiler about any 's' or 'mx' component properties the project may contain that are not supported on the JS side. EdB On Wed, Jul 2, 2014 at 4:57 PM, Justin Mclean wrote: > Hi, > > > 1) two new namespaces and accompanying projects in the main Flex SDK: > > vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you > > guessed it) MX and Spark components. > > Perhaps a friendlier namesace name? mxshim and sshim? or just mxjs and sjs? > > Justin > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: New Flex to JS project
Hi, > 1) two new namespaces and accompanying projects in the main Flex SDK: > vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you > guessed it) MX and Spark components. Perhaps a friendlier namesace name? mxshim and sshim? or just mxjs and sjs? Justin
Re: New Flex to JS project
As soon as I know what steps there are, sure ;-) I'll create a guide to using this stuff. The idea is to keep it simple: nothing special required on the MXML/AS side (business as usual, vanilla Flex), with an FB 'External Tool' to launch the JS publishing. The Installer should be able to handle most of the client side setup. For developers, things should also be relatively straight forward: create a shim for an MX or Spark component in either one of the new namespaces and then focus on implementing it's public API in JS. "That's all" :-P This will take substantial work on the FalconJX compiler, as I aim to use the Google Closure Tools to the max in the JS output and framework, and I plan to support only current versions of the major browsers, allowing me to do some ES5 and ES6 trickery ;-) EdB On Wed, Jul 2, 2014 at 3:53 PM, jude wrote: > If applicable please add the steps you take to the wiki so others can know > how to get started as well. IE, something like this for setting up your > environment, > https://cwiki.apache.org/confluence/display/FLEX/1.+Setting+up+the+SDK. > There may be something added since I last checked. > > > On Wed, Jul 2, 2014 at 5:57 AM, Erik de Bruin wrote: > > > Merge sounds like the way to go... Let's not revisit the whole Git usage > > thread(s) ;-) > > > > EdB > > > > > > > > > > On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala < > bigosma...@gmail.com > > > > > wrote: > > > > > On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz < > > christofer.d...@c-ware.de > > > > > > > wrote: > > > > > > > You don't loose the history when rebasing ... you sort of serialize > it. > > > Ok > > > > the order of commits is messed up, but I never really care about > this. > > > > It might look less interesting in a GIT visualization tool where you > > > could > > > > see tons of different branches and merges, but it should be a lot > > easier > > > to > > > > maintain, as a serial history is definiely the one that causes the > > least > > > > trouble ;-) > > > > > > > > In IntelliJ I usually set my "update" operation to "Rebase" using > > "Stash" > > > > and have never really had any problems. One click on "Update SCM" > and I > > > > still work on my featrue branch, but pull in all changes from develop > > or > > > > whatever branch I branched from. When it comes to commit, the commit > > > itself > > > > should be a fast-forward commit. > > > > > > > > But I guess there are several flavours here ... depending on the guy > > you > > > > ask or listen too, a different way will probably be recommended. I > > guess > > > > manually merging changes from develop to the feature branch is as > valid > > > as > > > > rebasing, but I think rebasing is easier and causes less trouble, but > > you > > > > loose the "real-order" of commits (Which I don't really care about). > > > > > > > > Chris > > > > > > > > > > I will let Erik decide if he wants to rebase or merge. My > recommendation > > > is that, since it is a feature branch, it will be useful to retain the > > > commit history intact. So, merge makes sense. > > > > > > If Erik does not want to keep the commit history intact, rebase will > just > > > work fine. > > > > > > Thanks, > > > Om > > > > > > > > > > > > > > > > > > > > > > > > > > Von: omup...@gmail.com im Auftrag von OmPrakash > > > > Muppirala > > > > Gesendet: Mittwoch, 2. Juli 2014 10:25 > > > > An: dev@flex.apache.org > > > > Betreff: Re: New Flex to JS project > > > > > > > > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin > > > wrote: > > > > > > > > > Ok, just checking: > > > > > > > > > > I create a local branch, let's call it 'vf2js', off > > 'origin/develop'. I > > > > > select this as my active branch. > > > > > > > > > > > > So far so good. > > > > > > > > > > > > > If I then 'rebase', all changes that have > > > > > been made to 'origin/develop' will be pulled into
Re: New Flex to JS project
If applicable please add the steps you take to the wiki so others can know how to get started as well. IE, something like this for setting up your environment, https://cwiki.apache.org/confluence/display/FLEX/1.+Setting+up+the+SDK. There may be something added since I last checked. On Wed, Jul 2, 2014 at 5:57 AM, Erik de Bruin wrote: > Merge sounds like the way to go... Let's not revisit the whole Git usage > thread(s) ;-) > > EdB > > > > > On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala > > wrote: > > > On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz < > christofer.d...@c-ware.de > > > > > wrote: > > > > > You don't loose the history when rebasing ... you sort of serialize it. > > Ok > > > the order of commits is messed up, but I never really care about this. > > > It might look less interesting in a GIT visualization tool where you > > could > > > see tons of different branches and merges, but it should be a lot > easier > > to > > > maintain, as a serial history is definiely the one that causes the > least > > > trouble ;-) > > > > > > In IntelliJ I usually set my "update" operation to "Rebase" using > "Stash" > > > and have never really had any problems. One click on "Update SCM" and I > > > still work on my featrue branch, but pull in all changes from develop > or > > > whatever branch I branched from. When it comes to commit, the commit > > itself > > > should be a fast-forward commit. > > > > > > But I guess there are several flavours here ... depending on the guy > you > > > ask or listen too, a different way will probably be recommended. I > guess > > > manually merging changes from develop to the feature branch is as valid > > as > > > rebasing, but I think rebasing is easier and causes less trouble, but > you > > > loose the "real-order" of commits (Which I don't really care about). > > > > > > Chris > > > > > > > I will let Erik decide if he wants to rebase or merge. My recommendation > > is that, since it is a feature branch, it will be useful to retain the > > commit history intact. So, merge makes sense. > > > > If Erik does not want to keep the commit history intact, rebase will just > > work fine. > > > > Thanks, > > Om > > > > > > > > > > > > > > > > > > > Von: omup...@gmail.com im Auftrag von OmPrakash > > > Muppirala > > > Gesendet: Mittwoch, 2. Juli 2014 10:25 > > > An: dev@flex.apache.org > > > Betreff: Re: New Flex to JS project > > > > > > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin > > wrote: > > > > > > > Ok, just checking: > > > > > > > > I create a local branch, let's call it 'vf2js', off > 'origin/develop'. I > > > > select this as my active branch. > > > > > > > > > So far so good. > > > > > > > > > > If I then 'rebase', all changes that have > > > > been made to 'origin/develop' will be pulled into my local branch? So > > > far, > > > > so good. > > > > > > > > > Rebase at this point is not required. The code from origin/develop is > > > already in the 'vf2js' branch. You will need to 'merge' from > > > origin/develop into vf2js once in a while to make sure that you are in > > sync > > > with whats happening with origin/develop. When you are done with the > > > feature, you just 'merge' vf2js into develop. If the history of the > > > 'vf2js' branch is not important, then you use the rebase option. > > > > > > > > > > But now I want the world to see what's in my local vf2js branch, > > > > so I 'publish' it. Is keeping the remote copy of my local branch up > to > > > date > > > > just a question of 'pushing' all commits to that remote branch? > > > > > > > > > Yes, that is correct. > > > > > > > > > > Will > > > > changes that come from the remote 'develop' via my local 'vf2js' also > > in > > > > the remote 'vf2js' that way? > > > > > > > > > > Cannot compute. Can you rephrase the question? > > > > > > > >
Re: New Flex to JS project
Merge sounds like the way to go... Let's not revisit the whole Git usage thread(s) ;-) EdB On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala wrote: > On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz > > wrote: > > > You don't loose the history when rebasing ... you sort of serialize it. > Ok > > the order of commits is messed up, but I never really care about this. > > It might look less interesting in a GIT visualization tool where you > could > > see tons of different branches and merges, but it should be a lot easier > to > > maintain, as a serial history is definiely the one that causes the least > > trouble ;-) > > > > In IntelliJ I usually set my "update" operation to "Rebase" using "Stash" > > and have never really had any problems. One click on "Update SCM" and I > > still work on my featrue branch, but pull in all changes from develop or > > whatever branch I branched from. When it comes to commit, the commit > itself > > should be a fast-forward commit. > > > > But I guess there are several flavours here ... depending on the guy you > > ask or listen too, a different way will probably be recommended. I guess > > manually merging changes from develop to the feature branch is as valid > as > > rebasing, but I think rebasing is easier and causes less trouble, but you > > loose the "real-order" of commits (Which I don't really care about). > > > > Chris > > > > I will let Erik decide if he wants to rebase or merge. My recommendation > is that, since it is a feature branch, it will be useful to retain the > commit history intact. So, merge makes sense. > > If Erik does not want to keep the commit history intact, rebase will just > work fine. > > Thanks, > Om > > > > > > > > > > > > Von: omup...@gmail.com im Auftrag von OmPrakash > > Muppirala > > Gesendet: Mittwoch, 2. Juli 2014 10:25 > > An: dev@flex.apache.org > > Betreff: Re: New Flex to JS project > > > > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin > wrote: > > > > > Ok, just checking: > > > > > > I create a local branch, let's call it 'vf2js', off 'origin/develop'. I > > > select this as my active branch. > > > > > > So far so good. > > > > > > > If I then 'rebase', all changes that have > > > been made to 'origin/develop' will be pulled into my local branch? So > > far, > > > so good. > > > > > > Rebase at this point is not required. The code from origin/develop is > > already in the 'vf2js' branch. You will need to 'merge' from > > origin/develop into vf2js once in a while to make sure that you are in > sync > > with whats happening with origin/develop. When you are done with the > > feature, you just 'merge' vf2js into develop. If the history of the > > 'vf2js' branch is not important, then you use the rebase option. > > > > > > > But now I want the world to see what's in my local vf2js branch, > > > so I 'publish' it. Is keeping the remote copy of my local branch up to > > date > > > just a question of 'pushing' all commits to that remote branch? > > > > > > Yes, that is correct. > > > > > > > Will > > > changes that come from the remote 'develop' via my local 'vf2js' also > in > > > the remote 'vf2js' that way? > > > > > > > Cannot compute. Can you rephrase the question? > > > > > > > > > > Thanks, > > > > > > EdB > > > > > > > > > > > > On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz < > > christofer.d...@c-ware.de > > > > > > > wrote: > > > > > > > No effort at all ... that's what GIT rebase is for. > > > > > > > > You can think of this sort of an automated "Create-Patch, Revert, > > Update, > > > > Apply Patch" ... if all goes well, it's just this one command, if > there > > > are > > > > conflicts, you get the usual conflict editor you would get anyway if > > you > > > > created conflicts on develop. > > > > > > > > Chris > > > > > > > > > > > > > > > > Von: Erik de Bruin > > > > Ge
Re: New Flex to JS project
On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz wrote: > You don't loose the history when rebasing ... you sort of serialize it. Ok > the order of commits is messed up, but I never really care about this. > It might look less interesting in a GIT visualization tool where you could > see tons of different branches and merges, but it should be a lot easier to > maintain, as a serial history is definiely the one that causes the least > trouble ;-) > > In IntelliJ I usually set my "update" operation to "Rebase" using "Stash" > and have never really had any problems. One click on "Update SCM" and I > still work on my featrue branch, but pull in all changes from develop or > whatever branch I branched from. When it comes to commit, the commit itself > should be a fast-forward commit. > > But I guess there are several flavours here ... depending on the guy you > ask or listen too, a different way will probably be recommended. I guess > manually merging changes from develop to the feature branch is as valid as > rebasing, but I think rebasing is easier and causes less trouble, but you > loose the "real-order" of commits (Which I don't really care about). > > Chris > I will let Erik decide if he wants to rebase or merge. My recommendation is that, since it is a feature branch, it will be useful to retain the commit history intact. So, merge makes sense. If Erik does not want to keep the commit history intact, rebase will just work fine. Thanks, Om > > > > > Von: omup...@gmail.com im Auftrag von OmPrakash > Muppirala > Gesendet: Mittwoch, 2. Juli 2014 10:25 > An: dev@flex.apache.org > Betreff: Re: New Flex to JS project > > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin wrote: > > > Ok, just checking: > > > > I create a local branch, let's call it 'vf2js', off 'origin/develop'. I > > select this as my active branch. > > > So far so good. > > > > If I then 'rebase', all changes that have > > been made to 'origin/develop' will be pulled into my local branch? So > far, > > so good. > > > Rebase at this point is not required. The code from origin/develop is > already in the 'vf2js' branch. You will need to 'merge' from > origin/develop into vf2js once in a while to make sure that you are in sync > with whats happening with origin/develop. When you are done with the > feature, you just 'merge' vf2js into develop. If the history of the > 'vf2js' branch is not important, then you use the rebase option. > > > > But now I want the world to see what's in my local vf2js branch, > > so I 'publish' it. Is keeping the remote copy of my local branch up to > date > > just a question of 'pushing' all commits to that remote branch? > > > Yes, that is correct. > > > > Will > > changes that come from the remote 'develop' via my local 'vf2js' also in > > the remote 'vf2js' that way? > > > > Cannot compute. Can you rephrase the question? > > > > > > Thanks, > > > > EdB > > > > > > > > On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz < > christofer.d...@c-ware.de > > > > > wrote: > > > > > No effort at all ... that's what GIT rebase is for. > > > > > > You can think of this sort of an automated "Create-Patch, Revert, > Update, > > > Apply Patch" ... if all goes well, it's just this one command, if there > > are > > > conflicts, you get the usual conflict editor you would get anyway if > you > > > created conflicts on develop. > > > > > > Chris > > > > > > > > > > > > Von: Erik de Bruin > > > Gesendet: Mittwoch, 2. Juli 2014 09:50 > > > An: dev@flex.apache.org > > > Betreff: Re: New Flex to JS project > > > > > > Hi Chris, > > > > > > Thanks for the feedback. > > > > > > I'm talking about FalconJX, not Falcon. The latter is the "new" SWF > > > compiler, the former is the Flex to JavaScript cross compiler. > > > > > > I guess a feature branch might work... But I'm afraid that keeping that > > > branch up to date with the 'develop' branch will add extra work. How to > > > best handle that part, so I don't spend what little time I have on Git > > > stuff instead of code? > > > > > > EdB > >
AW: New Flex to JS project
You don't loose the history when rebasing ... you sort of serialize it. Ok the order of commits is messed up, but I never really care about this. It might look less interesting in a GIT visualization tool where you could see tons of different branches and merges, but it should be a lot easier to maintain, as a serial history is definiely the one that causes the least trouble ;-) In IntelliJ I usually set my "update" operation to "Rebase" using "Stash" and have never really had any problems. One click on "Update SCM" and I still work on my featrue branch, but pull in all changes from develop or whatever branch I branched from. When it comes to commit, the commit itself should be a fast-forward commit. But I guess there are several flavours here ... depending on the guy you ask or listen too, a different way will probably be recommended. I guess manually merging changes from develop to the feature branch is as valid as rebasing, but I think rebasing is easier and causes less trouble, but you loose the "real-order" of commits (Which I don't really care about). Chris Von: omup...@gmail.com im Auftrag von OmPrakash Muppirala Gesendet: Mittwoch, 2. Juli 2014 10:25 An: dev@flex.apache.org Betreff: Re: New Flex to JS project On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin wrote: > Ok, just checking: > > I create a local branch, let's call it 'vf2js', off 'origin/develop'. I > select this as my active branch. So far so good. > If I then 'rebase', all changes that have > been made to 'origin/develop' will be pulled into my local branch? So far, > so good. Rebase at this point is not required. The code from origin/develop is already in the 'vf2js' branch. You will need to 'merge' from origin/develop into vf2js once in a while to make sure that you are in sync with whats happening with origin/develop. When you are done with the feature, you just 'merge' vf2js into develop. If the history of the 'vf2js' branch is not important, then you use the rebase option. > But now I want the world to see what's in my local vf2js branch, > so I 'publish' it. Is keeping the remote copy of my local branch up to date > just a question of 'pushing' all commits to that remote branch? Yes, that is correct. > Will > changes that come from the remote 'develop' via my local 'vf2js' also in > the remote 'vf2js' that way? > Cannot compute. Can you rephrase the question? > > Thanks, > > EdB > > > > On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz > > wrote: > > > No effort at all ... that's what GIT rebase is for. > > > > You can think of this sort of an automated "Create-Patch, Revert, Update, > > Apply Patch" ... if all goes well, it's just this one command, if there > are > > conflicts, you get the usual conflict editor you would get anyway if you > > created conflicts on develop. > > > > Chris > > > > > > > > Von: Erik de Bruin > > Gesendet: Mittwoch, 2. Juli 2014 09:50 > > An: dev@flex.apache.org > > Betreff: Re: New Flex to JS project > > > > Hi Chris, > > > > Thanks for the feedback. > > > > I'm talking about FalconJX, not Falcon. The latter is the "new" SWF > > compiler, the former is the Flex to JavaScript cross compiler. > > > > I guess a feature branch might work... But I'm afraid that keeping that > > branch up to date with the 'develop' branch will add extra work. How to > > best handle that part, so I don't spend what little time I have on Git > > stuff instead of code? > > > > EdB > > > > > > > > > > On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz < > christofer.d...@c-ware.de > > > > > wrote: > > > > > I think the reason for the overlay is that by this we are tricking the > > > FlashBuilder to use Falcon instead of the old compiler. > > > It should be possible to have Falcon separate from the normal compiler. > > > It's just that FlashBuilder will probably not be albe to use it that > way. > > > Probably IntelliJ would support this withn a few hours, Flexmojos > within > > a > > > few weeks and FlashBuilder never ;-) > > > > > > You shouldn't implement this in the develop branch but create a > > > feature-branch instead that forks off the develop branch. This way your > > > changes are available to anyone interested and as soon as the featu
Re: New Flex to JS project
On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin wrote: > Ok, just checking: > > I create a local branch, let's call it 'vf2js', off 'origin/develop'. I > select this as my active branch. So far so good. > If I then 'rebase', all changes that have > been made to 'origin/develop' will be pulled into my local branch? So far, > so good. Rebase at this point is not required. The code from origin/develop is already in the 'vf2js' branch. You will need to 'merge' from origin/develop into vf2js once in a while to make sure that you are in sync with whats happening with origin/develop. When you are done with the feature, you just 'merge' vf2js into develop. If the history of the 'vf2js' branch is not important, then you use the rebase option. > But now I want the world to see what's in my local vf2js branch, > so I 'publish' it. Is keeping the remote copy of my local branch up to date > just a question of 'pushing' all commits to that remote branch? Yes, that is correct. > Will > changes that come from the remote 'develop' via my local 'vf2js' also in > the remote 'vf2js' that way? > Cannot compute. Can you rephrase the question? > > Thanks, > > EdB > > > > On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz > > wrote: > > > No effort at all ... that's what GIT rebase is for. > > > > You can think of this sort of an automated "Create-Patch, Revert, Update, > > Apply Patch" ... if all goes well, it's just this one command, if there > are > > conflicts, you get the usual conflict editor you would get anyway if you > > created conflicts on develop. > > > > Chris > > > > > > > > Von: Erik de Bruin > > Gesendet: Mittwoch, 2. Juli 2014 09:50 > > An: dev@flex.apache.org > > Betreff: Re: New Flex to JS project > > > > Hi Chris, > > > > Thanks for the feedback. > > > > I'm talking about FalconJX, not Falcon. The latter is the "new" SWF > > compiler, the former is the Flex to JavaScript cross compiler. > > > > I guess a feature branch might work... But I'm afraid that keeping that > > branch up to date with the 'develop' branch will add extra work. How to > > best handle that part, so I don't spend what little time I have on Git > > stuff instead of code? > > > > EdB > > > > > > > > > > On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz < > christofer.d...@c-ware.de > > > > > wrote: > > > > > I think the reason for the overlay is that by this we are tricking the > > > FlashBuilder to use Falcon instead of the old compiler. > > > It should be possible to have Falcon separate from the normal compiler. > > > It's just that FlashBuilder will probably not be albe to use it that > way. > > > Probably IntelliJ would support this withn a few hours, Flexmojos > within > > a > > > few weeks and FlashBuilder never ;-) > > > > > > You shouldn't implement this in the develop branch but create a > > > feature-branch instead that forks off the develop branch. This way your > > > changes are available to anyone interested and as soon as the feature > is > > > finished, you merge it back to develop. > > > > > > Chris > > > > > > Von: Erik de Bruin > > > Gesendet: Mittwoch, 2. Juli 2014 09:33 > > > An: dev@flex.apache.org > > > Betreff: New Flex to JS project > > > > > > Hi, > > > > > > I'm working on creating a way to publish vanilla Flex SDK projects to > > > JavaScript on latest gen browsers. This project consists of several sub > > > projects, and I'm wondering what is the best way forward with regard to > > > contributing them: > > > > > > 1) two new namespaces and accompanying projects in the main Flex SDK: > > > vf2js_mx and vf2js_s. These namespaces will contain shim objects for > (you > > > guessed it) MX and Spark components. > > > > > > 2) two new code paths in FalconJX: one for AS and one for MXML > > > > > > 3) a new JavaScript library for the components and shims for AS classes > > > > > > 4) a testing framework for the JS components, loosely based on > Marmotinni > > > > > > Questions: > > > > > > A - I would very much like to work in the 'de
AW: New Flex to JS project
Have a look at this ... I think it explains things quite well. https://www.youtube.com/watch?v=cSf8cO0WB4o Chris Von: Erik de Bruin Gesendet: Mittwoch, 2. Juli 2014 10:07 An: dev@flex.apache.org Betreff: Re: New Flex to JS project Ok, just checking: I create a local branch, let's call it 'vf2js', off 'origin/develop'. I select this as my active branch. If I then 'rebase', all changes that have been made to 'origin/develop' will be pulled into my local branch? So far, so good. But now I want the world to see what's in my local vf2js branch, so I 'publish' it. Is keeping the remote copy of my local branch up to date just a question of 'pushing' all commits to that remote branch? Will changes that come from the remote 'develop' via my local 'vf2js' also in the remote 'vf2js' that way? Thanks, EdB On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz wrote: > No effort at all ... that's what GIT rebase is for. > > You can think of this sort of an automated "Create-Patch, Revert, Update, > Apply Patch" ... if all goes well, it's just this one command, if there are > conflicts, you get the usual conflict editor you would get anyway if you > created conflicts on develop. > > Chris > > > ____________ > Von: Erik de Bruin > Gesendet: Mittwoch, 2. Juli 2014 09:50 > An: dev@flex.apache.org > Betreff: Re: New Flex to JS project > > Hi Chris, > > Thanks for the feedback. > > I'm talking about FalconJX, not Falcon. The latter is the "new" SWF > compiler, the former is the Flex to JavaScript cross compiler. > > I guess a feature branch might work... But I'm afraid that keeping that > branch up to date with the 'develop' branch will add extra work. How to > best handle that part, so I don't spend what little time I have on Git > stuff instead of code? > > EdB > > > > > On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz > > wrote: > > > I think the reason for the overlay is that by this we are tricking the > > FlashBuilder to use Falcon instead of the old compiler. > > It should be possible to have Falcon separate from the normal compiler. > > It's just that FlashBuilder will probably not be albe to use it that way. > > Probably IntelliJ would support this withn a few hours, Flexmojos within > a > > few weeks and FlashBuilder never ;-) > > > > You shouldn't implement this in the develop branch but create a > > feature-branch instead that forks off the develop branch. This way your > > changes are available to anyone interested and as soon as the feature is > > finished, you merge it back to develop. > > > > Chris > > > > Von: Erik de Bruin > > Gesendet: Mittwoch, 2. Juli 2014 09:33 > > An: dev@flex.apache.org > > Betreff: New Flex to JS project > > > > Hi, > > > > I'm working on creating a way to publish vanilla Flex SDK projects to > > JavaScript on latest gen browsers. This project consists of several sub > > projects, and I'm wondering what is the best way forward with regard to > > contributing them: > > > > 1) two new namespaces and accompanying projects in the main Flex SDK: > > vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you > > guessed it) MX and Spark components. > > > > 2) two new code paths in FalconJX: one for AS and one for MXML > > > > 3) a new JavaScript library for the components and shims for AS classes > > > > 4) a testing framework for the JS components, loosely based on Marmotinni > > > > Questions: > > > > A - I would very much like to work in the 'develop' branches of the > > projects involved, but especially on the part of '1)' I'm not sure if I > did > > it right. All tests I can think of seem to pass, but maybe someone has > the > > time to do a code review on a branch that I can publish? > > > > B - In order for this to work, FalconJX needs to be part of the regular > SDK > > distribution. Folks who did this on the FlexJS overlay: what does it take > > to make FalconJX part of the SDK? > > > > That's it, for now :-) > > > > Thanks, > > > > EdB > > > > > > > > -- > > Ix Multimedia Software > > > > Jan Luykenstraat 27 > > 3521 VB Utrecht > > > > T. 06-51952295 > > I. www.ixsoftware.nl > > > > > > -- > Ix Multimedia Software > > Jan Luykenstraat 27 > 3521 VB Utrecht > > T. 06-51952295 > I. www.ixsoftware.nl > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: New Flex to JS project
> > > B - In order for this to work, FalconJX needs to be part of the regular > SDK > > distribution. > Why not make it an optional download via the installer ant script / > installer? > Because that is just what this project needs, more complexity. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: New Flex to JS project
Ok, just checking: I create a local branch, let's call it 'vf2js', off 'origin/develop'. I select this as my active branch. If I then 'rebase', all changes that have been made to 'origin/develop' will be pulled into my local branch? So far, so good. But now I want the world to see what's in my local vf2js branch, so I 'publish' it. Is keeping the remote copy of my local branch up to date just a question of 'pushing' all commits to that remote branch? Will changes that come from the remote 'develop' via my local 'vf2js' also in the remote 'vf2js' that way? Thanks, EdB On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz wrote: > No effort at all ... that's what GIT rebase is for. > > You can think of this sort of an automated "Create-Patch, Revert, Update, > Apply Patch" ... if all goes well, it's just this one command, if there are > conflicts, you get the usual conflict editor you would get anyway if you > created conflicts on develop. > > Chris > > > ____________ > Von: Erik de Bruin > Gesendet: Mittwoch, 2. Juli 2014 09:50 > An: dev@flex.apache.org > Betreff: Re: New Flex to JS project > > Hi Chris, > > Thanks for the feedback. > > I'm talking about FalconJX, not Falcon. The latter is the "new" SWF > compiler, the former is the Flex to JavaScript cross compiler. > > I guess a feature branch might work... But I'm afraid that keeping that > branch up to date with the 'develop' branch will add extra work. How to > best handle that part, so I don't spend what little time I have on Git > stuff instead of code? > > EdB > > > > > On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz > > wrote: > > > I think the reason for the overlay is that by this we are tricking the > > FlashBuilder to use Falcon instead of the old compiler. > > It should be possible to have Falcon separate from the normal compiler. > > It's just that FlashBuilder will probably not be albe to use it that way. > > Probably IntelliJ would support this withn a few hours, Flexmojos within > a > > few weeks and FlashBuilder never ;-) > > > > You shouldn't implement this in the develop branch but create a > > feature-branch instead that forks off the develop branch. This way your > > changes are available to anyone interested and as soon as the feature is > > finished, you merge it back to develop. > > > > Chris > > > > Von: Erik de Bruin > > Gesendet: Mittwoch, 2. Juli 2014 09:33 > > An: dev@flex.apache.org > > Betreff: New Flex to JS project > > > > Hi, > > > > I'm working on creating a way to publish vanilla Flex SDK projects to > > JavaScript on latest gen browsers. This project consists of several sub > > projects, and I'm wondering what is the best way forward with regard to > > contributing them: > > > > 1) two new namespaces and accompanying projects in the main Flex SDK: > > vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you > > guessed it) MX and Spark components. > > > > 2) two new code paths in FalconJX: one for AS and one for MXML > > > > 3) a new JavaScript library for the components and shims for AS classes > > > > 4) a testing framework for the JS components, loosely based on Marmotinni > > > > Questions: > > > > A - I would very much like to work in the 'develop' branches of the > > projects involved, but especially on the part of '1)' I'm not sure if I > did > > it right. All tests I can think of seem to pass, but maybe someone has > the > > time to do a code review on a branch that I can publish? > > > > B - In order for this to work, FalconJX needs to be part of the regular > SDK > > distribution. Folks who did this on the FlexJS overlay: what does it take > > to make FalconJX part of the SDK? > > > > That's it, for now :-) > > > > Thanks, > > > > EdB > > > > > > > > -- > > Ix Multimedia Software > > > > Jan Luykenstraat 27 > > 3521 VB Utrecht > > > > T. 06-51952295 > > I. www.ixsoftware.nl > > > > > > -- > Ix Multimedia Software > > Jan Luykenstraat 27 > 3521 VB Utrecht > > T. 06-51952295 > I. www.ixsoftware.nl > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: New Flex to JS project
Hi, > A - I would very much like to work in the 'develop' branches of the > projects involved Would be better if you work in a branch, if you;re worried about getting out of date just merge develop into your branch every now and then. Git tools eg source tree can make this easier for you. > B - In order for this to work, FalconJX needs to be part of the regular SDK > distribution. Why not make it an optional download via the installer ant script / installer? Thanks, Justin
AW: New Flex to JS project
No effort at all ... that's what GIT rebase is for. You can think of this sort of an automated "Create-Patch, Revert, Update, Apply Patch" ... if all goes well, it's just this one command, if there are conflicts, you get the usual conflict editor you would get anyway if you created conflicts on develop. Chris Von: Erik de Bruin Gesendet: Mittwoch, 2. Juli 2014 09:50 An: dev@flex.apache.org Betreff: Re: New Flex to JS project Hi Chris, Thanks for the feedback. I'm talking about FalconJX, not Falcon. The latter is the "new" SWF compiler, the former is the Flex to JavaScript cross compiler. I guess a feature branch might work... But I'm afraid that keeping that branch up to date with the 'develop' branch will add extra work. How to best handle that part, so I don't spend what little time I have on Git stuff instead of code? EdB On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz wrote: > I think the reason for the overlay is that by this we are tricking the > FlashBuilder to use Falcon instead of the old compiler. > It should be possible to have Falcon separate from the normal compiler. > It's just that FlashBuilder will probably not be albe to use it that way. > Probably IntelliJ would support this withn a few hours, Flexmojos within a > few weeks and FlashBuilder never ;-) > > You shouldn't implement this in the develop branch but create a > feature-branch instead that forks off the develop branch. This way your > changes are available to anyone interested and as soon as the feature is > finished, you merge it back to develop. > > Chris > ________ > Von: Erik de Bruin > Gesendet: Mittwoch, 2. Juli 2014 09:33 > An: dev@flex.apache.org > Betreff: New Flex to JS project > > Hi, > > I'm working on creating a way to publish vanilla Flex SDK projects to > JavaScript on latest gen browsers. This project consists of several sub > projects, and I'm wondering what is the best way forward with regard to > contributing them: > > 1) two new namespaces and accompanying projects in the main Flex SDK: > vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you > guessed it) MX and Spark components. > > 2) two new code paths in FalconJX: one for AS and one for MXML > > 3) a new JavaScript library for the components and shims for AS classes > > 4) a testing framework for the JS components, loosely based on Marmotinni > > Questions: > > A - I would very much like to work in the 'develop' branches of the > projects involved, but especially on the part of '1)' I'm not sure if I did > it right. All tests I can think of seem to pass, but maybe someone has the > time to do a code review on a branch that I can publish? > > B - In order for this to work, FalconJX needs to be part of the regular SDK > distribution. Folks who did this on the FlexJS overlay: what does it take > to make FalconJX part of the SDK? > > That's it, for now :-) > > Thanks, > > EdB > > > > -- > Ix Multimedia Software > > Jan Luykenstraat 27 > 3521 VB Utrecht > > T. 06-51952295 > I. www.ixsoftware.nl > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: New Flex to JS project
Hi Chris, Thanks for the feedback. I'm talking about FalconJX, not Falcon. The latter is the "new" SWF compiler, the former is the Flex to JavaScript cross compiler. I guess a feature branch might work... But I'm afraid that keeping that branch up to date with the 'develop' branch will add extra work. How to best handle that part, so I don't spend what little time I have on Git stuff instead of code? EdB On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz wrote: > I think the reason for the overlay is that by this we are tricking the > FlashBuilder to use Falcon instead of the old compiler. > It should be possible to have Falcon separate from the normal compiler. > It's just that FlashBuilder will probably not be albe to use it that way. > Probably IntelliJ would support this withn a few hours, Flexmojos within a > few weeks and FlashBuilder never ;-) > > You shouldn't implement this in the develop branch but create a > feature-branch instead that forks off the develop branch. This way your > changes are available to anyone interested and as soon as the feature is > finished, you merge it back to develop. > > Chris > > Von: Erik de Bruin > Gesendet: Mittwoch, 2. Juli 2014 09:33 > An: dev@flex.apache.org > Betreff: New Flex to JS project > > Hi, > > I'm working on creating a way to publish vanilla Flex SDK projects to > JavaScript on latest gen browsers. This project consists of several sub > projects, and I'm wondering what is the best way forward with regard to > contributing them: > > 1) two new namespaces and accompanying projects in the main Flex SDK: > vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you > guessed it) MX and Spark components. > > 2) two new code paths in FalconJX: one for AS and one for MXML > > 3) a new JavaScript library for the components and shims for AS classes > > 4) a testing framework for the JS components, loosely based on Marmotinni > > Questions: > > A - I would very much like to work in the 'develop' branches of the > projects involved, but especially on the part of '1)' I'm not sure if I did > it right. All tests I can think of seem to pass, but maybe someone has the > time to do a code review on a branch that I can publish? > > B - In order for this to work, FalconJX needs to be part of the regular SDK > distribution. Folks who did this on the FlexJS overlay: what does it take > to make FalconJX part of the SDK? > > That's it, for now :-) > > Thanks, > > EdB > > > > -- > Ix Multimedia Software > > Jan Luykenstraat 27 > 3521 VB Utrecht > > T. 06-51952295 > I. www.ixsoftware.nl > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
AW: New Flex to JS project
I think the reason for the overlay is that by this we are tricking the FlashBuilder to use Falcon instead of the old compiler. It should be possible to have Falcon separate from the normal compiler. It's just that FlashBuilder will probably not be albe to use it that way. Probably IntelliJ would support this withn a few hours, Flexmojos within a few weeks and FlashBuilder never ;-) You shouldn't implement this in the develop branch but create a feature-branch instead that forks off the develop branch. This way your changes are available to anyone interested and as soon as the feature is finished, you merge it back to develop. Chris Von: Erik de Bruin Gesendet: Mittwoch, 2. Juli 2014 09:33 An: dev@flex.apache.org Betreff: New Flex to JS project Hi, I'm working on creating a way to publish vanilla Flex SDK projects to JavaScript on latest gen browsers. This project consists of several sub projects, and I'm wondering what is the best way forward with regard to contributing them: 1) two new namespaces and accompanying projects in the main Flex SDK: vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you guessed it) MX and Spark components. 2) two new code paths in FalconJX: one for AS and one for MXML 3) a new JavaScript library for the components and shims for AS classes 4) a testing framework for the JS components, loosely based on Marmotinni Questions: A - I would very much like to work in the 'develop' branches of the projects involved, but especially on the part of '1)' I'm not sure if I did it right. All tests I can think of seem to pass, but maybe someone has the time to do a code review on a branch that I can publish? B - In order for this to work, FalconJX needs to be part of the regular SDK distribution. Folks who did this on the FlexJS overlay: what does it take to make FalconJX part of the SDK? That's it, for now :-) Thanks, EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
New Flex to JS project
Hi, I'm working on creating a way to publish vanilla Flex SDK projects to JavaScript on latest gen browsers. This project consists of several sub projects, and I'm wondering what is the best way forward with regard to contributing them: 1) two new namespaces and accompanying projects in the main Flex SDK: vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you guessed it) MX and Spark components. 2) two new code paths in FalconJX: one for AS and one for MXML 3) a new JavaScript library for the components and shims for AS classes 4) a testing framework for the JS components, loosely based on Marmotinni Questions: A - I would very much like to work in the 'develop' branches of the projects involved, but especially on the part of '1)' I'm not sure if I did it right. All tests I can think of seem to pass, but maybe someone has the time to do a code review on a branch that I can publish? B - In order for this to work, FalconJX needs to be part of the regular SDK distribution. Folks who did this on the FlexJS overlay: what does it take to make FalconJX part of the SDK? That's it, for now :-) Thanks, EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
