Adobe Flex 3 Help

Compiling modules

The way you compile modules is similar to the way you compile Flex applications. On the command line, you use the mxmlc command-line compiler; for example:

mxmlc MyModule.mxml 

The result of compiling a module is a SWF file that you load into your application. You cannot run the module-based SWF file as a stand-alone application or load it into a browser window. It must be loaded by an application as a module. Modules should not be requested by the Adobe® Flash® Player or Adobe® AIR,™ or through a browser directly.

When you compile your module, you should try to remove redundancies between the module and the application that uses it. To do this, you create a link report for the application, and then externalize any assets in the module that appear in that report. Flex Builder can do this for you automatically. For more information, see Reducing module size.

Reducing module size

Module size varies based on the components and classes that are used in the module. By default, a module includes all framework code that its components depend on, which can cause modules to be large by linking classes that overlap with the application's classes.

To reduce the size of the modules, you can optimize the module by instructing it to externalize classes that are included by the application. This includes custom classes and framework classes. The result is that the module includes only the classes it requires, while the framework code and other dependencies are included in the application.

To externalize framework classes with the command-line compiler, you generate a linker report from the application that loads the modules. You then use this report as input to the module's load-externs compiler option. The compiler externalizes all classes from the module for which the application contains definitions. This process is also necessary if your modules are in a separate project from your main application in Flex Builder.

Create and use a linker report with the command-line compiler

  1. Generate the linker report and compile the application:
    mxmlc -link-report=report.xml MyApplication.mxml
    
    

    The default output location of the linker report is the same directory as the compiler. In this case, it would be in the bin directory.

  2. Compile the module and pass the linker report to the load-externs option:
    mxmlc -load-externs=report.xml MyModule.mxml
    
    

Recompiling modules

If you change a module, you do not have to recompile the application that uses the module if that module is in the same project. This is because the application loads the module at run time and does not check against it at compile time. Similarly, if you make changes to the application, you do not have to recompile the module. Just as the application does not check against the module at compile time, the module does not check against the application until run time.

If the module is in a separate project than the application that loads it, you must recompile the module separately.

However, if you make changes that might affect the linker report or common code, you should recompile both the application and the modules.

Note: If you externalize the module's dependencies by using the load-externs or optimize option, your module might not be compatible with future versions of Adobe Flex. You might be required to recompile the module. To ensure that a future Flex application can use a module, compile that module with all the classes it requires. This also applies to applications that you load inside other applications.

Debugging modules

To debug an application that uses modules, you set the debug compiler option to true for the modules when you compile them. Otherwise, you will not be able to set breakpoints in the modules or gather other debugging information from them. In Flex Builder, debugging is enabled by default. On the command line, debugging is disabled by default. You must also set the debug option to true when you compile the application that loads the modules that you want to debug.

A common issue that occurs when using multiple modules is that modules sometimes own the class definitions that the other modules want to use. Because they are in sibling application domains, the module that loaded the class definition first owns the definition for that class, but other modules will experience errors when they try to use that class. The solution is to promote the class definition to the main application domain so that all modules can use the class. For more information, see Module domains.