flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik de Bruin <e...@ixsoftware.nl>
Subject Re: New Flex to JS project
Date Wed, 02 Jul 2014 15:42:43 GMT
> 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



Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message