Parsley allows you to build a hierarchy of Contexts that can be dynamically loaded and unloaded. This hierarchy can be built no matter whether you are using Flex Modules or not, even in pure AS3 applications. For Flex Modules Parsley just offers an additional level of integration in that it makes it easier to deal with multiple different ApplicationDomains.
In larger applications you may want to split your application into modules which are loaded on demand. In this case it would be unfortunate to have a monolithic Context that is fully loaded and initialized at application startup. Even splitting the configuration into multiple files like shown in 3.7 Combining multiple Configuration mechanisms won't help since those files will be merged into a single Context and loaded and initialized as if it was a single large configuration file.
This is where another feature of Parsley comes in handy: when creating a Context
it can connect to a parent Context. The parent may be the main context loaded at
application startup for example and the child context may be one required by a module loaded on demand.
In the configuration for the child Context you can use any object from the parent Context for Dependency Injection
(but not vice versa). Messaging also works across Context boundaries, depending on the scope you dispatch through.
You can create deeply nested hierarchies of Contexts, but often the structure would be rather flat, with one
root context and any number of child Contexts on the same level.
There are two different ways to initialize such a child Context:
Connecting a Context hierarchy to a view hierarchy
When you are specifying a view root with any of the static ContextBuilder entry points,
or when you are using the MXML ContextBuilder tags introduced with version 2.2 which automatically
use the document they are placed upon as a view root, then
the ViewManager associated with the Context will use that view root for two purposes:
it will listen for bubbling events from components that wish to get wired to the Context and
it will listen for bubbling events from other ContextBuilders sitting somewhere below in the
view hierarchy. This way you do not have to manually specify the parent Context or the
ApplicationDomain, the framework will take care of that for you:
<parsley:ContextBuilder config="{BookStoreConfig}"/>
or:
var viewRoot:DisplayObject = ...;
FlexContextBuilder.build(BookStoreConfig, viewRoot);
In the examples above the new Context will use the view root to automatically look for a parent Context and to listen for child Contexts within the view hierarchy.
In some scenarios you may want to keep the Context hierarchy separate from the view hierarchy. This is where the second option for building the hierarchy comes into play:
Manually specifying the parent Context
You can define an existing Context as the parent for a new Context with an optional parameter of all the various ContextBuilder methods shown in 3 Configuration and Initialization:
var parent:Context = ...;
FlexContextBuilder.build(BookStoreConfig, null, parent);
In this case we pass null for the view root parameter and instead specify the parent
manually. You must also be aware of the fact that without a view root the Context is not able
to automatically detect the ApplicationDomain for reflection. So if you are not working in the
root ApplicationDomain but instead in a child domain of a loaded Flex Module for example,
you also have to pass the domain to the builder method:
var parent:Context = ...;
var domain:ApplicationDomain = ...;
FlexContextBuilder.build(BookStoreConfig, null, parent, domain);
Again this is not necessary when specifying a view root, since the builder is then able to automatically detect the parent Context and the ApplicationDomain.
If you load multiple Context instances as modules like described
in the previous section, you may want to get rid of them when you unload a module - without
affecting the parent. Actually that is quite easy, just do this:
context.destroy();
When connecting a Context hierarchy to a view hierarchy it is
even easier. You don't have to explicitly destroy the Context then, it will happen automatically
when the last view root associated with the Context gets removed from the stage.
This is the default behaviour of the ViewManager which can be adjusted in case
you do not want the Context lifecycle to depend on the time the view is on the stage.
You can finetune the behaviour with properties of the ViewManagerFactory.
When a Context gets destroyed the following actions occur:
MessageRouter. This affects all elements annotated with MessageHandler, MessageBinding,
MessageInterceptor or MessageError. ManagedEvents they will be ignored from now
on and no longer dispatched trough Parsleys messaging system. [Destroy] (or the corresponding MXML or XML tags)
on any object of the destroyed Context get invoked. destroy. Any subsequent method invocations
on that Context throw Errors. The parent of the destroyed Context (if any) is not affected and may continue
to operate normally. In version 2.0.x the framework offered a special ContextModule MXML tag to specify
the configuration for the module. This is no longer needed. The framework specific ContextModule and ModuleLoader
tags have been removed. Instead the support for Flex Modules is now fully transparent. You load
a Module either with the regular Flex ModuleLoader tag or with the Flex ModuleManager.
You can then create child Contexts anywhere within that Module, it does not have to happen in
the root Module component. If you connect the Context hierarchy to the view hierarchy like demonstrated in the preceding sections
the child Context will automatically determine the parent Context and the ApplicationDomain
of the Module.