...
This page provides an overview of the typical way to use the IoC system in a component. There are variations on this theme, but this overview provides a basic, full-function implementation.
IoC Overview
Infusion components make use of the Framework's IoC system through two main mechanisms which work together:
...
The author of an Infusion component describes the structure of part of an IoC component tree that is rooted at a particular component, by describing what subcomponents the component has.
Declaring Subcomponents
A parent component declares what subcomponents it requires through the components block of the parent component's default options using fluid.defaults. This list of subcomponents will be examined when the parent component ask the Framework to create subcomponents, as described below in #Creating Subcomponents.
| Section | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
For more information on how components can declare subcomponents, see Subcomponent Declaration. For details on the fluid.defaults() function, please see its API page.
Creating Subcomponents
A component creator function must call fluid.initDependents to instantiate any subcomponents declared in the defaults. The call to fluid.initDependents will create each of the subcomponents using the demands specifications registered using fluid.demands.
...
| width | 60% |
|---|
...
myNamespace.myComponentName = function (container, options) {
var that = initView(...);
...
fluid.initDependents(that);
...
return that;
};
| Column |
|---|
Assuming this example is combined with the demands specifications and component defaults shown above, when |
Every component of grade "autoInit" will call it's fluid.initDependents function during its lifecycle in order to initialize any of its subcomponents.The call to fluid.initDependents will create each of the subcomponents using the demands specifications registered using fluid.demands.
...
| width | 60% |
|---|
...
fluid.defaults("myNamespace.myComponentName", {
gradeNames: ["autoInit", ...],
...,
components: {
mySubComponent1: {
type: "subComponent1Name"
},
mySubComponent2: {
type: "subComponent2Name"
},
},
...
});
| Column |
|---|
|
For more information on the fluid.initDependents() function, please see its API page.
IoC Value Resolution
The first stage of resolution involves a search of the component tree around the site of the issued IoC reference to assemble the set of context names which constitute the environment of the call. The diagram shown here shows graphically (in yellow) the set of components in the tree which are considered in scope during resolution which is initiated from the component shown in green:
The results of these simultaneous searches selects the closest match - a match occurs if the context name it mentions resolves to a context name found in the environment.
The result will be either:
- no context is found matching the requested function call - in this case, undefined is returned
OR - one or more contexts are found matching the IoC reference - In this case, the system will select the closest match from the set of matching contexts, and use this as value assigned to the property.
Value Resolution of Arguments
When an IoC reference is provided, it directs the framework to replace the property with a different value, source from the environment surrounding the IoC Reference. This process involves value resolution. Path expressions (contextualised "EL expressions"), strings of the following form may be used to represent values drawn from elsewhere in the tree, and during value resolution, will be replaced by the value which they match:
...
"{contextName}.path1.path2"
This matching of contexts proceeds by the same scoping rules as in the diagram above. The numbers in the top left corners of the yellow boxes show the sequence in which the environment of the call site will be searched for components matching the requested context name. The first match found in this sequence for contextName will select that component, and the patch path1.path2(etc.) will be used to resolve a property or sub-property of the component.
Examples
...
// need example
Any IoC References which appear in the definition of a component tree will be resolved onto their targets in the component tree as it constructs. This process occurs in a data-driven way - if the reference is resolved onto a part of the component tree which has not yet constructed at the point of the reference, the framework will shift its workflow to instantiating the target of the reference in order to resolve it.