Versions Compared

Old Version 19

changes.mady.by.user Antranig Basman

Saved on

compared with

New Version 20

changes.mady.by.user Antranig Basman

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

In the Infusion IoC system, a component declares its (static) subcomponents through the components property of the defaults, using fluid.defaults:

...

Property

Type

Description

Example

type

String

This is the grade name of the type of subcomponent to be created. May be an IoC Reference.

Code Block
javascript
javascript
subcomponent1: {
    type: "my.component.gradename"
}
options (Optional)ObjectThese are options to be passed to the subcomponent as "user options." Note that these are not the default options for the subcomponent, rather these options override the defaults. The defaults for the component will have already been registered by the fluid.defaults call(s) appropriate for its type and grade names.
Code Block
subcomponent1: {
    type: "fluid.mySubcomponent",
    options: {
        myOptions: "{name}.options.someOption",
        ...
    }
}

createOnEvent (Optional)

String

Specifies an event that will trigger the creation of the subcomponent. This option is used when the subcomponent should not be created immediately as part of the construction process of its parent, but rather at a later time signalled by the firing of the specified event. If this value is a simple string, it represents an event held on the parent component - it may also take the form of an IoC reference to an event elsewhere in the component tree.

Note that if the specified event fires multiple times, the corresponding component will be destroyed and then recreated on every firing of the event after the first time.

Code Block
javascript
javascript
subcomponent1: {
    type: "fluid.mySubcomponent",
    createOnEvent: "someEvent"
}

priority (Optional)

Number or "first"/"last"

Specifies the order priority of the creation of the particular subcomponent. During component tree instantiation, the framework will sort the collection of subcomponents based on the priority specified. Note that use of this option should be discouraged as it leads to fragile configuration. If you find yourself using it, please report the instance to the development team to see if a better solution can be found.

Code Block
javascript
javascript
subcomponent1: {
    type: "fluid.mySubcomponent",
    priority: "first"
}
container (Required only for View components)StringThis property is a CSS-style selector identifying the container element to be used for this subcomponent. This property is required for any View components. 

Injected Subcomponent Declaration

...

Code Block
fluid.defaults("gpii.explorationTool.modelTransformer", {
    gradeNames: ["fluid.modelComponent", "fluid.uiOptions.modelRelay", "autoInit"],
    components: {
        highContrast: { // complex subcomponent declaration with priority and createOnEvent
            type: "gpii.explorationTool.panels.highContrast",
            container: "{uiOptions}.dom.highContrast",
            createOnEvent: "{uiOptions}.events.onUIOptionsMarkupReady",
            priority: "first",
            options: {
                resources: {
                    template: "{templateLoader}.resources.highContrast"
                }
            }
        }
    }
});

Dynamic

...

components

A powerful facility known as dynamic (sub)components allows you to direct the framework to construct a number of subcomponents whose number is not known in advance from a template subcomponent record. There are two principal varieties of dynamic components. The first requires the existence of a source array for the construction - at run-time, the framework will inspect the array you refer to and construct one component from your template for each element of the array. The components which get constructed in this way can each be contextualised by both the contents of the corresponding array element as well as its index. The second requires the existence of a source event for the construction. The framework will construct one subcomponent for each firing of the event - the constructed component can be contextualised by the arguments that the event was fired with.

...