Hi,
I think I finally have the dual branch operational enough for folks to
poke at. There is one issue with FB integration where it keeps starting a
compile right after the previous compile finishes. I'm looking into that
today, but for now I just go to Project Properties and switch to another
FlexJS SDK.
One goal of the dual branch was to have one invocation of the compiler
generate both SWF and JS output. That way, if you are using an IDE like
FlashBuilder and save your changes, the compiler will generate both SWF
and JS and catch any differences in the underlying APIs.
Another goal was to allow FlexJS classes to generate overrides of Flash
classes but with FlexJS types. This would give us better control over the
APIs presented to FlexJS customers. For example, in Flash, Sprite has a
dispatchEvent method that takes a flash.events.Event. We'd like to tell
our users that UIBase has a dispatchEvent that takes an
org.apache.flex.events.Event. But if you write:
class UIBase extends Sprite
{
override public function
dispatchEvent(event:org.apache.flex.events.Event):Boolean
{
}
}
The compiler normally returns an error since the base class has:
public function dispatchEvent(event:flash.events.Event):Boolean
But now we can add metadata to our dispatchEvent override.
[SWFOverride(params="flash.events.Event",
altparams="org.apache.flex.events.Event:org.apache.flex.events.MouseEvent")
]
override public function
dispatchEvent(event:org.apache.flex.events.Event):Boolean
And the FlexJS compiler will allow the override without an error.
However, it will actually generate SWF code for event being a
flash.events.Event since the runtime would otherwise throw an exception
about illegal overrides. As long as org.apache.flex.events.Event extends
flash.events.Event on the SWF side, then the code will operate normally in
the player.
The combination of these two goals make Flash Builder integration a bit
more seamless. Before, you would save your changes and compile a SWF,
then go and run an Eclipse launch script that ran the cross-compiler. And
errors found during the cross-compile couldn't be clicked on in the
problems pane. But now, on each save you spend a bit more time compiling
for both platforms, but you immediately see errors against the JS APIs and
can examine them from the problems pane. I found some missing APIs while
testing this.
In addition, the flex-config.xml and air-config.xml files have between
tweaked to be JS-oriented. IOW, the external-library-path and
library-path in those files point to JS.swc and the FlexJS JS SWCs (like
BasicJS.swc). This means that code-hinting is oriented towards the JS API
surface. That prevents a lot of Flash-only APIs from showing up in the
code hinting. We might want to figure out a way to hide APIs since some
of the offerings don't have Flash support either.
One cool outcome of this work is that we can now generate the JS output
without playerglobal.swc or airglobal.swc. I think they are needed for
Flash Builder to think of the SDK as a Flex SDK, but if you are not using
FB and just using Ant or Maven, it should be possible to create a release
package for those Ant and Maven customers that have no Adobe dependencies!
Of course, that means that you won't get SWF output, which I think is
still beneficial for many reasons, but if you think you don't need the SWF
output, we could come up with a release package that is truly all ALv2
compatible.
I made changes to the Maven mojos to exercise this dual output code, but
I'm waiting on Christofer and other maven experts to decide whether I've
broken any Maven rules. Maven doesn't really need these changes since
you essentially dictate what outputs you want in the POM anyway. The main
benefit of dual output was for IDEs like Flash Builder.
Anyway, you can try to use the Installer and install the FlexJS Dual build
or build it from the repos. If you use the repos, be sure to get both the
flex-falcon and flex-asjs dual branches and build flex-falcon first.
Let me know what you think.
-Alex
