Generally speaking, some components will react to events generated by the user, such as selector type components; others will react to changes in parameters, such as chart components; some will react to both types of changes, such as table components. A component’s response to such changes prompts the component to enter its lifecycle, where its execution and behavior is controlled via a set of properties which are common to most of the components.
You can set most of the following lifecycle properties on the Properties panel in the Components perspective. Note that you will want to click Advanced Properties to access all the available properties for a component.
| Property | Description |
|---|---|
| Type | This property assumes a variety of values such as ComponentsParameter, ComponentsSelect, and ComponentscccBarChart. You cannot edit this property through the CDE interface. It is set on the backend. |
| Name | This property is the identifier of the component. It is recommended you use camel case when entering a name for a component. |
| Parameter | For components such as the Select component, the Filter Component and others where user input is required, this field is where the input is stored for later use throughout the dashboard. |
| Listeners | This property is composed of the dashboard parameters which may trigger a component’s reaction. These parameters allow for interaction between components, allowing you to control when some components will execute and in which order. For example, you may have a component which will only be executed after a change to a parameter which the component is listening to. A component can have more than one parameter in the Listeners property, and a parameter can be listened by more than one component. Every time the parameter changes, all the components which listen to it are updated in the dashboard. |
| Parameters | On the case of xAction components, PRPT components, Query components, and others, some parameters may be passed by specifying the desired value in an array of arrays. |
| HtmlObject | This is the ID of the HTML object on which the component will be appended to. This ID corresponds to the name you attributed to the HTML column element onto which you want to place the component. |
| Priority | Use this property to control the order in which the dashboard elements are executed. By default a component’s priority is set to 5. The lower the number, the higher the priority the component has. Note that components with the same priority value may not be executed at the same time, so if order of execution is critical, assign priority. |
| Execute at Start | This property controls whether or not the component will execute when the dashboard loads itself. By default, this property is set to True. In the cases where this property is set to False, the component will only be executed when a change occurs in one of the parameters which the component is listening to. |
| Pre Execution/Post Execution | These functions are executed before/after the component is initialized, updated, or presented to the user. If the preExecution returns false, the component is not updated. |
| Pre Change/Post Change | These properties are for component selectors. Before/after the input value is updated, these functions are executed. This property is useful for validating user input. |
| Post Fetch | This function is involved if the update stage calls queries. Once the query is executed, the data returned is passed to the postFetch function. The component is rendered only after the execution of this function. |
To sum up, a component is initialized when a dashboard first loads. The component will check the value of the Execute At Start property, and if this value is set to True, the component will enter the pre-execution function and execute any code which is set here. For instance, in this phase the component can set itself to use a specific query, or fetch the contents of a parameter for its own use. The component will then update itself, entering the post-execution function. After completing this cycle, the component will wait for changes to the parameters to which it is listening to. A change to one of these parameters will cause the component to pre-execute, update, and post-execute.
When a parameter is changed, the component evaluates whether the change was triggered by a user event. If this is the case and the change has not originated in a selector, a fire change occurs. The information that a parameter has been changed is propagated to the dashboard and any components listening to that parameter will execute themselves.
If the parameter change occurred via a selector, the component will execute any pre-change instructions, as well as any post-change instructions, after the fire change event. Following this occurrence, the component will remain in wait of any changes to the parameters it is listening to. This lifecycle is further illustrated in the following image:
