CIF processing
Last updated
Last updated
When the CIF starts the following process is carried out:
The initial processing starts after the crcReady
event is fired
The cubbles in the root context are processed and their child components' elements are created.
When all pending tags are created and are ready, the cifAllComponentsReady
event is fired.
The main processing is started
All connection tags are created
The connection tags are parsed, and all connections are registered in the proper context
The slot init tags are created
The cifInitStart
event is fired, and init tags are
parsed,
sorted and
processed
The cifInitReady
event is fired
If this process is called from the initial processing, a mutation summary observer is created
The following image illustrates this process:
To explain the processing of components, let's assume that we are processing a context that have two root components, an elementary and a compound, as illustrated below:
To process that tree, the CIF carry the following process out:
Elementary1
is processed
The required attributes are created (e.g., runtime-id, member-id, etc)
Hint: when processing existing elements, some required attributes will be created and some existing attribute values will be checked and adjusted to make them valid in the current context.
Compound1
is processed
The required attributes are created (e.g., runtime-id, member-id, etc)
Notify that pending components for Compound1
exist
Sub-element for Elementary2
Compound2
is processed
The required attributes are created (e.g., runtime-id, member-id, etc)
Notify that pending components for Compound2
exist
Each of the components; i.e., Elementary1
, Elementary2
, Elementary3
and Elementary4
fires the componentReady
event. The CIF
registers all components first as unready. After the components fire the componentReady
event, the register will changed to ready. The CIF
registers the pending elements (not yet created sub-elements) for each component too. If all components are ready and no pending components exists anymore, the cifAllComponentsReady
event will be fired.
This process is illustrated below:
Hint: members' elements are created in the order in which they appear in the manifest definition of a compound; or, if a template exists, members are imported and processed in the order in which they appear in the template.
Sub-element for Compound2
is created and attached
Notify that no pending component for Compound1
exists anymore
componentReady
event for Compound1
is fired
Sub-element for Elementary3
is created and attached
Sub-element for Elementary3
is created and attached
Notify that no pending component for Compound2
exists anymore
componentReady
event for Compound2
is fired