Versions Compared

Old Version 2

changes.mady.by.user Alex Harui

Saved on

compared with

New Version 3

changes.mady.by.user Alex Harui

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

You’ll see in the code @flexjsignorecoercion for native HTMLElements as well.  There might be a better way to do this, but that’s what we’re using for now.

JS-only or SWF-only Components

Sometimes a component only needs to exist for the SWF version and the class dependencies don't require that a class is defined for the JS version (and vice-versa).  An example is the ScrollBar-related code.  The SWF versions of Container and List are capable of using ScrollBar-capable views but the JS version of Container and List and their views don't reference Scrollbars because they are built into the browser's DIV (the JS views simply toggle ScrollBar-related styles on the DIV).  Same for Borders and Backgrounds.  For cases like these, the components have so far never been in the MXML manifest and are only listed in the XXXClasses file (for Core.swc, CoreClasses.as).  The pattern to use is to use COMPILE::AS3 or COMPILE::JS around the line for that component in the XXXClasses file.  If you use the "Different Inheritance" pattern above, it can cause errors as then the source file actually looks empty to the compiler.  So the best option is not to compile it at all.  Below is an excerpt from CoreClasses.as.

 

Code Block
    import org.apache.flex.utils.EffectTimer; EffectTimer;
    import org.apache.flex.utils.MixinManager; MixinManager;
	COMPILE::AS3
	{
	    import org.apache.flex.utils.PNGEncoder; PNGEncoder;
    	import org.apache.flex.utils.SolidBorderUtil; SolidBorderUtil;
	    import org.apache.flex.utils.StringTrimmer; StringTrimmer;
    }
	import org.apache.flex.utils.Timer; Timer;
    import org.apache.flex.utils.CSSUtils; CSSUtils;
	COMPILE::JS
	{
	    import org.apache.flex.utils.Language; Language;
	}

In this snippet you can see that PNGEncoder, SolidBorderUtil and StringTrimmer are only needed for SWF versions, and org.apache.flex.utils.Language is only used in JS versions.

 

Build-related Files

There are several files involved in building the SWC.  The goal is to cross-compile the JS version, then compile the SWF version and create a  SWC that includes the .JS files from the cross-compile.

The build.xml file for a SWC should have 3 main steps:

  1. compile-asjs:  This cross-compiles the JS version using the js.swc from Falcon (as opposed to playerglobal.swc or airglobal.swc) for the "built-in" classes (Object, Array, String, Number, etc).  The COMPILE::AS3 flag should be false and the COMPILE::JS flag should be true.
  2. compile-extern-swc:  This compiles a SWF for a SWC but still using the js.swc from Falcon.  This SWC is placed in an externs folder for use as a dependent SWC by downstream SWCs.  This SWC is needed so that only the API surfaces exposed by COMPILE::JS are available to consumers of this SWC.  Application developers should never need to access these SWCs, only downstream SWC developers.
  3. compile: This is the final phase that compiles a SWF for a SWC with COMPILE::AS3 true and COMPILE::JS false and using playergloba.swcl or airglobal.swc for the built-in classes.

 

The list of files that are compiled by each phase is controlled by a compile-asjs-config.xml file for steps 1 and 2, and compile-config.xml for step 3.  

The compile-asjs-config.xml file

  • Should have an empty external-library-path entry.  The external-library-path is specified in build.xml so we can use Ant to resolve the reference to js.swc in the Falcon repo
  • Should use upstream SWCs from the externs folder, not the libs folder (so that the API surfaces are the ones exposed by COMPILE::JS

The compile-config.xml file

  • Should have playerglobal.swc or airglobal.swc as the external-library-path entry
  • Should use upstream SWCs from the libs folder and not the externs folder
  • Should have "include-file" entries for the js/out folder
Code Block
    <include-file>
        <name>js/out/*</name>
        <path>js/out/*</path>
    </include-file>

The build.xml not only includes the JS files in the SWC, but also copies them to frameworks/js/FlexJS/libs.  The FalconJX compiler is told to look at frameworks/js/FlexJS/libs first, then look in the SWCs.  This is done to enable folks to monkey-patch JS files in frameworks/js/FlexJS/libs and not have to rebuild a SWC.  The danger is that a stale file in frameworks/js/FlexJS/libs can override your changes that went into the SWC.