> > 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" <e...@ixsoftware.nl> 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 > > > >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
