In this excerpt from our book, Rich Internet Applications, we'll cover how to set up large applications intended for Web or, more broadly speaking, distributed deployment. As an example let's consider an enterprise application that consists of hundreds of screens, reports, forms, and dashboards. Accordingly, about a dozen engineers specializing in GUIs, frameworks, data layers, and business domains are working on this application in parallel.

Every application "run" in Flex Builder as well as the invocation of the application's MXML file processed by the Web-tier Flex compiler requires an application build. Needless to say, this takes time. The bigger the application, the more time it takes.

Developers need a fast process of building and deploying their applications.

The application also has to be partitioned for team development both vertically (application screens) and horizontally (UI, skins, reusable components, and back-end code). Imagine working on two "portlets," one of them showing a DataGrid and the other a TreeView. You have a choice: either package a 1MB module with both portlets or download separate ones (500K each) on demand. The latter way has the additional benefit of isolating the work between the team members.

Finally, the model should allow the extensibility of the product, meaning the integration of patches and portlet-style add-ons as well as external Flex subsystems shouldn't impact the main build.

We'll try to accommodate these requirements emphasizing the productivity of team development and deployment flexibility. But first let's review the deployment scenarios from the business point-of-view in detail.

Deployment Scenarios
Throughout this excerpt we'll use the term patches, which are the fixes and additions made to an application between releases. Add-ons are the parts of the application that are typically added over time. Similar to patches add-ons blend seamlessly into the hosting application, both visually and programmatically.

In some cases the application build may not even "know" about specific add-ons since they're different for each user type. For example, an enterprise application can reveal more screens or more functionality within these screens to internal users. In this case we talk about portlet-style add-ons.

Plug-ins are independent applications that don't share the look-and-feel of the main application. No intensive interaction between the main application and plug-ins is expected.

Application Domains 101
As much as we don't like to duplicate the work done by the Adobe Flex documentation team, we have to cover the subject of Application Domains since it's essential to this chapter. So, here are the facts.

All code loaded from an SWF file lands in one or another application domain. Conversely, instances of the flash.system.ApplicationDomain class stores the tables of the ActionScript 3.0 definitions and class definitions in particular.

A system domain contains all the application domains and there's a current domain where the main application runs. There's also a parent domain for each domain except the system one. System domains, quite naturally, happen to be the parent of the main application's domain.

The definition of the loaded classes as long as they remain loaded can't be overriden down the parental chain. Attempts to reload a class that's already been loaded by its parent will fail. If you're coming from the Java side, you may have seen a similar mechanism called Java ClassLoader.

We also have to mention the security domains of the Flash Player, since partitioning the classes (visibility) via application domains is within the confines of the security domains. The choice of a security domain is relevant for use cases when we need to load an SWF file coming from a different server, which is outside the scope of this chapter.

So, an application domain is the mechanism that (a) supports multiple definitions of the same class where children can access parent definitions seamlessly or (b) lets child definitions be tentatively merged with parent ones so that accessing the other party's definitions is seamless for both the child and the parent.

This mechanism is enacted by flash.display.Loader and mx.controls.SWFLoader controls.

The first choice is represented by the syntax new ApplicationDomain(Appli cationDomain.currentDomain) while the second one is ApplicationDomain.currentDomain.

A specific sub-case of (a) is the use of a system domain as a parent: new ApplicationDomain(null), which results in the ultimate separation of the (class) definitions, eliminating any overshadowing.

Either way, the required application domain is getting assigned the applicationDomain property of a Flash.system.LoaderContext instance, which, in turn is used as an argument to construct a flash.system.Loader, or acts as a property of an mx.controls.SWFLoader.

There are nuiances in accessing child definitions from the parent as well as in loading/accessing possibly overshadowing the class definitions.

When you bring existing Flex subsystems (perhaps even written in a different version of Flex) under a common application umbrella, it makes sense to resort to a separate application domain. At the same time, if you need to dynamically load DataGrid definitions, it makes sense to load them in the same application domain where the main application is running.

Runtime Shared Libraries 101
Flex documentation defines Runtime Shared Libraries (RSL) as "a library of components." We would like to start with the clarification that RSL is not a file but a pattern of using an SWF file from within another SWF file.

Specifically, SWFs marked as RSLs are automatically pre-loaded during the application's bootstrap as opposed to being explicitly loaded by the code you write. To be exact, definitions contained in the SWF are loaded into the applicationDomain of the hosting application.

Now how does the application's bootstrap know which SWF files are to be pre-loaded?

Here is an answer. Let's assume that:
a)  You made the file FlexLibrary.SWC (using the compc compiler explicitly or from within the Flex Builder's Library Project);
b)  You've created the file FlexApplication.mxml, which refers to components from FlexLibrary.SWC;
c)  While compiling FlexApplication.mxml you instructed the mxmlc compiler that FlexLibrary.SWC contains an image of an SWF to be pre-loaded during the bootstrap (this will be explained later in this chapter).

Then, the corresponding ActionScript file generated by the mxmlc compiler will have the code fragment shown below. You'll find this and other files in the generated folder of your application project once you set the compiler's option to keep-generated-actionscript=true:

public class _FlexApplication_mx_managers_SystemManager extends mx.managers.SystemManager
implements IFlexModuleFactory {
    public function _FlexApplication_mx_managers_SystemManager() {
super();
    }
      override public function info():Object {
      return {
        "currentDomain": ApplicationDomain.currentDomain,
        "layout" : "absolute",
        "mainClassName" : "FlexApplication",
        "mixins" : ["_FlexApplication_FlexInit", ......]
        ,
        "rsls" : [{url: "FlexLibrary.swf", size: -1}]
    };
}
}
}

As a reminder, the SystemManager is a parent of all the displayable objects within the application, such as the main window (an instance of mx.core.Application), pop-ups, cursors, etc. SystemManager also creates the mx.preloaders.Preloader that loads SWF files.

Please note that FlexLibrary.swf is not an RSL. As we said above, RSL is a usage pattern rather than a file. What makes FlexLibrary.swf part of this pattern is the intent to pre-load it during the application startup communicated by us to the mxmlc compiler.

    "currentDomain": ApplicationDomain.currentDomain,

This illustrates that the RSL approach results in class definitions from the library are loaded into the same domain where the definition of the application classes belong. That's why, in particular, we find the RSL technique especially useful for delivering various patches, which should be loaded prior to any other class definitions.

SWFs and SWCs: What's Under the Hood How do our SWC files relate to SWFs? Like every Flex SWC, FlexLibrary.SWC contains the library.swf and catalog.xml files. The latter describes the hierarchy of dependencies found in library.swf, which can potentially become FlexLibrary.swf (depending on the selected link type described below).

When we compile FlexApplication.mxml containing references to FlexLibrary.SWC in the library search path, there are three link types to choose from:

• External - The catalog.xml in the FlexLibrary.swc will be used to resolve references; however the code contained in library.swf won't be included in the body of the FlexApplication.swf. The External link type assumes that by the time FlexApplication needs to create instances of classes from the library.swf part the definitions for these classes will somehow get loaded in the relevant applicationDomain.
• RSL - The catalog.xml in the FlexLibrary.swc will be used to resolve references; code contained in library.swf won't be included in the body of the FlexApplication.swf. So far sounds like External, right? Here's the difference: all definitions originally contained in the library.swf part will be upfront-loaded into the main applicationDomain during application startup.
• Merge-in - Classes that are explicitly referenced by the code (and their dependencies) explicitly get included in the FlexApplication.swf. This is a default option for statically linked applications and guarantees that the definitions of all referenced classes as well as the classes they depend on are loaded into the main applicationDomain outright.

Suppose we went with dynamic linking via RSL. As illustrated in the previous code fragment, this means pre-loading the FlexLibrary.swf. Here's the question: where do we get this FlexLibrary.swf from? Under one scenario we can let Flex Builder extract and rename the library.swf from the FlexLibrary.swc. In Flex Builder (project Properties >Flex Build Path> Library Path) this option is called Auto extract swf. Alternatively, we could have declined auto-extracting and unzipped the SWF from the SWC ourselves. As we'll show later, there's yet another way of explicitly controlling the upfront build of FlexLibrary.swf.

We'll illustrate these cases in the next section.

Making the FlexLibrary.swc
Let's make an SWC in Flex Builder by creating a new Flex Library Project. The only component we're going to add to this SWC is the CustomPanel from the following code which enumerates the instances of itself and imprints the number of the instance as part of its title, using the variable instanceNumber that we've declared bindable:

<?xml version="1.0" encoding="utf-8"?>
<!-- CustomPanel.mxml -->
<mx:Panel xmlns:mx="http://www.adobe.com/2006/mxml" title="'Custom' Panel
#{instanceNumber}" width="300" height="150" creationComplete="instanceNumber=++count;" >
    <mx:Script>
      public static var count:int;
      [Bindable]
      private var instanceNumber:int;
    </mx:Script>
</mx:Panel>

To ensure that our CustomPanel is accounted for (in both library.swf and catalog.xml) we have to verify that it's included in the Flex Library Build Path. Please be aware that every time you add or rename files in your Library Project the corresponding checkbox in Flex Builder gets cleared.

After we click OK, Flex Builder will invoke the compc compiler to create the FlexLibrary.swc in the output bin folder.