Documentation for a historical release of Infusion: 1.4
Please view the Infusion Documentation site for the latest documentation, or the Infusion 1.3. Documentation for the previous release.
If you're looking for Fluid Project coordination, design, communication, etc, try the Fluid Project Wiki.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

This functionality is Sneak Peek status. This means that the APIs may change. We welcome your feedback, ideas, and code, but please use caution if you use this new functionality.

Before component creation:

  • Components register their defaults using fluid.defaults, including defaults for subcomponents and invokers. This is accomplished the components and invokers blocks respectively.
  • Subcomponents and invokers register their demands for various contexts, using fluid.demands.
  • Demands context can either be a one of ancestor components, or a component, registered in the static environment.

On component creation:

  1. The component's registered defaults are expanded as part of the initial that creation (i.e. through fluid.initView or one of its alternatives). This involves invocation of any expanders (currently supported: deferredCall, deferredInvokeCall, deferredFetcher and noexpand)
    NOTE that expanders within the options of any subcomponents will NOT be expanded - this will happen within the subcomponent's own creation pipeline

  2. Any user-supplied options along with the options specified in appropriate demands block are merged with the expanded defaults (also as part of the initial that creation) to produce the component's options i.e. that.options

  3. Dependent subcomponents are initialized (through fluid.initDependents)
    1. Demands registered for the subcomponents are resolved, that is, they are:
      • determined (selected from registered demands based on closest matching contexts), and then
      • embodied (resolved to concrete function names and argument values)
    2. Arguments for the subcomponents are expanded i.e. any expanders are applied (currently supported: deferredCall, deferredInvokeCall, deferredFetcher and noexpand)
    3. The subcomponent creator function is called
      Note: this will, itself, trigger the same pipeline process for the subcomponent

  4. Invokers are created (also in fluid.initDependents)
    1. Demands registered for the invoker are determined (selected from registered demands based on closest matching contexts) but not embodied i.e. value resolution of supercomponent references will not be carried out
    2. An invoker is returned (and attached to the that) such that the demands will be embodied (resolved to concrete function names and argument values) upon invocation
  • No labels