About application domains
An application domain is a container for class definitions. Applications have a single, top-level application domain called the system domain. When you load a sub-application into another, main application, you can load it into one of three application domains: sibling, child, and current. Each of these locations defines where the sub-application can get its class definitions from.
The System domain
Classes defined by Flash Player are in the system domain. The system domain parents all other application domains. The main application’s application domain is a child of the system domain. Classes defined in the system domain are never redefined in sub-applications or main applications. Those applications all share the common definitions of Flash Player. These definitions include classes such as DisplayObject, Event, and Sprite. The definitions of these shared classes are contained in the playerglobal.swc file.
Sibling applicaton domains
The application domain that a sub-application is in determines where the sub-application gets its class definitions from. If the main application loads a sub-application into a sibling application domain, the sub-application defines its own non-player class definitions. This is the configuration for multi-versioned applications.
Child application domains
If a main application loads a sub-application into a child application domain of its application domain, the subapplication gets its class definitions from the main application. This behavior is the default for application loading. It can result in runtime errors if the applications are compiled with different versions of the Flex framework. These errors occur because the applications are sometimes compiled against different definitions of the same classes.
If a sub-application defines one of the classes that is already defined in the main application, the child’s definition is ignored. If multiple sub-applications define the same class that isn’t defined in the main application, each sub-application uses its own definition.
The current application domain
If you load a sub-application into the current application domain, the sub-application’s class definitions are often ignored. This behavior is because the first definition in a domain is used. Subsequent definitions loaded into that domain are ignored. If new class definitions are added, the main application can use them.
Using the current application domain is typical of RSLs and other specially compiled resources, and is not typically used when loading sub-applications.
Setting application domain
You specify the application domain of a sub-application by setting the value of the loadForCompatibility property on the SWFLoader. If you set the value of this property to true, then the sub-application is loaded into a sibling application domain. If you set the value of this property to false (default), then the sub-application is loaded into a child application domain.
You can also specify the application domain on the LoaderContext object. You do this if you specify the value of the loaderContext property when using the SWFLoader control.
An application domain is a container for class definitions. Applications have a single, top-level application domain called the system domain. When you load a sub-application into another, main application, you can load it into one of three application domains: sibling, child, and current. Each of these locations defines where the sub-application can get its class definitions from.
The System domain
Classes defined by Flash Player are in the system domain. The system domain parents all other application domains. The main application’s application domain is a child of the system domain. Classes defined in the system domain are never redefined in sub-applications or main applications. Those applications all share the common definitions of Flash Player. These definitions include classes such as DisplayObject, Event, and Sprite. The definitions of these shared classes are contained in the playerglobal.swc file.
Sibling applicaton domains
The application domain that a sub-application is in determines where the sub-application gets its class definitions from. If the main application loads a sub-application into a sibling application domain, the sub-application defines its own non-player class definitions. This is the configuration for multi-versioned applications.
Child application domains
If a main application loads a sub-application into a child application domain of its application domain, the subapplication gets its class definitions from the main application. This behavior is the default for application loading. It can result in runtime errors if the applications are compiled with different versions of the Flex framework. These errors occur because the applications are sometimes compiled against different definitions of the same classes.
If a sub-application defines one of the classes that is already defined in the main application, the child’s definition is ignored. If multiple sub-applications define the same class that isn’t defined in the main application, each sub-application uses its own definition.
The current application domain
If you load a sub-application into the current application domain, the sub-application’s class definitions are often ignored. This behavior is because the first definition in a domain is used. Subsequent definitions loaded into that domain are ignored. If new class definitions are added, the main application can use them.
Using the current application domain is typical of RSLs and other specially compiled resources, and is not typically used when loading sub-applications.
Setting application domain
You specify the application domain of a sub-application by setting the value of the loadForCompatibility property on the SWFLoader. If you set the value of this property to true, then the sub-application is loaded into a sibling application domain. If you set the value of this property to false (default), then the sub-application is loaded into a child application domain.
You can also specify the application domain on the LoaderContext object. You do this if you specify the value of the loaderContext property when using the SWFLoader control.
Note: The value of the loadForCompatibility property is ignored if you explicitly set the value of the loaderContext property.
Nenhum comentário:
Postar um comentário