flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: New Flex to JS project
Date Wed, 09 Jul 2014 14:28:32 GMT


On 7/9/14 2:04 AM, "Erik de Bruin" <erik@ixsoftware.nl> 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=<oldURI>$<newURI>.  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 current SDK.  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.

I'm not sure what advantages you get from merging VJS into the main SDK.
Seems like it would make the packaging of current SDK more complex and tie
you to successful releases of the current SDK and vice versa.  Wouldn't
you be more nimble just referencing the current SDK SWCs and releasing as
a separate package?  At least in the early going?  IMO, I think were
better off keeping Falcon separate from the current SDK as well, at least
for now.

Hmm, well that was shorter than the last post, I think...
-Alex


Mime
View raw message