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:
When you are specifying a view root with the ContextBuilder API
or when you are using the MXML ContextBuilder tag introduced which automatically
uses the document it is 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 = ...;
ContextBuilder
.newSetup()
.viewRoot(viewRoot)
.newBuilder()
.config(FlexConfig.forClass(BookStoreConfig))
.build();
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:
You can define an existing Context as the parent for a new Context when using the ContextBuilder API:
var parent:Context = ...;
ContextBuilder
.newSetup()
.parent(parent)
.newBuilder()
.config(FlexConfig.forClass(BookStoreConfig))
.build();
In this case we did not specify a view root at all (note that you cannot dynamically wire views to this Context in this case) 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 = ...;
ContextBuilder
.newSetup()
.parent(parent)
.domain(domain)
.newBuilder()
.config(FlexConfig.forClass(BookStoreConfig))
.build();
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.
This is a feature that was introduced with version 2.4. Before that the Context hierarchy was limited to a tree structure, so while each Context could have multiple children, it always only had one parent. The option to specify more than one parent adds a lot more flexibility for building a Context hierarchy. For example it would allow to build a set of libraries that can depend on each other and connect their Contexts accordingly.
Let's assume you are working with two modules that might be needed by multiple other (otherwise unrelated) modules in the application and that both have their own Context:
var messaging:Context = ...;
var persistence:Context = ...;
If you'd then build another Context that needs injections from messaging and persistence, you could instruct the ContextBuilder to use both Contexts as parents:
<parsley:ContextBuilder config="{BookStoreConfig}" parents="{[messaging, persistence]}"/>
When using the ContextBuilder tag it would also automatically look for a parent in the view hierarchy. So in case it would find a parent, you'd have three parents.
You can alternatively instruct the ContextBuilder not to look for a parent in the hierarchy:
<parsley:ContextBuilder
config="{BookStoreConfig}"
parents="{[messaging, persistence]}"
findParentInView="false"
/>
Finally, of course the ContextBuilder API also allows you to use this feature. You simply invoke
the parent method multiple times:
ContextBuilder
.newSetup()
.viewRoot(viewRoot)
.parent(messaging)
.parent(persistence)
.newBuilder()
.config(FlexConfig.forClass(BookStoreConfig))
.build();
Context Precedence for Dependency Lookups
When a Context looks up a dependency, it first looks if it finds it amongst its own definitions. If unsuccessful it starts to look into the parents one after the other. The order will be the same that you specified when constructing the Context. When there is also a parent that was automatically found in the view hierarchy, it will always be used as the last Context for lookups.
When using dependency injection by type (without specifying an id), it is important that the dependency is not ambiguous. It means that a single Context should not have more than managed object of a matching type. It does not matter whether other Contexts have matching types, too, as the lookup will stop at the Context where the first matching instance is found.
ApplicationDomains for Shared Contexts
Realistically the only option for a Shared Context is to exist in the root ApplicationDomain. If you use multiple modules that all get loaded into a child ApplicationDomain, it would become difficult to share anything between those modules which is not in the root ApplicationDomain. This is because sibling ApplicationDomains do not see each others class definitions. This also means that such a shared module cannot be unloaded once it has been used. This is important to keep in mind when planning for the maximum memory consumption of very large applications.
Loading and Initializing Shared Contexts on Demand
The features introduced with version 2.4 are only the start. That version added the low-level hooks in the core APIs to be able to build a flexible Context hierarchy where each Context can have multiple parents. As you could see from the samples given above, you still have to manage these shared Contexts yourself. So it is the responsibility of your application to know which parents are needed by which Context and where and how to obtain and construct these Context instances. So for a very large application you'd probably still build some level of infrastructure on top of this existing Parsley feature.
In the future (sometime after the release of Parsley 3.0), there'll be a separate Parsley extension project that builds on top of this. It would allow you to specify available shared Contexts in a simple XML manifest and the framework will then load and initialize the parents when they are needed for the first time.
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,
CommandResult and so on. 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.