About component references

Uses for component references

There are two common situations where you might want to use component references.

• It is a good practice to develop and test your business logic in a modular fashion by building each trigger system in a separate workspace. For production, you often want to include several trigger systems in a single workspace. Component references provide an easy way to copy complete trigger systems from one workspace into another workspace.
• Some components have complex logic that takes some time to configure. When you want to replicate this logic in a different workspace, you can use a component reference.

Workspace origin

When you paste a component reference into a workspace, the name of the workspace from which you copied the component is shown in parentheses after the component name in the component list. This helps you identify the components that are shared across workspaces.

The following rules apply.

• When you change the name of a workspace from which component references are copied, all the component references from that workspace have their workspace origin name changed to the new workspace name.
• If you delete a workspace that is the origin workspace of shared components, the shared components with that workspace origin have their workspace origin name changed to Deleted_N, where a number is added to the name to ensure the uniqueness of the Workspace Origin name.
• You can change the workspace origin of a shared component by clicking Change Workspace Origin in the component editor. This is especially useful for components with a workspace origin name of Deleted_N.

Component reference rules

The following rules apply to operations you perform on referenced components.

• In general, when you paste a component reference into a workspace, all of the ancestors of that component are also pasted into the workspace.
• There are two exceptions to the rule that ancestors of the referenced component are copied.
  1. When a reference is made to a Container, only the Container and any components it depends upon to calculate its time span are copied and pasted into the new workspace.

     This is because Container components are a way to create a sophisticated data structure that you can use within your trigger system. You can configure field names, apply functions to the fields, and set up a time span and aggregation rules. You might want to re-use this structure without including all of the ancestors of the Container.

     • If a container depends on a Select or an Expression component to calculate its time span, the Select or Expression is copied, and the ancestors of the Select or Expression are also copied.
     • If a container depends on another Container to calculate its time span, the other Container is also copied, and Container rules regarding the time span are applied.
  2. When a reference is made to a Container Manipulator that writes to a Container, the Container is the descendent of the Container Manipulator. However, both the Container Manipulator and the Container it writes to are copied.

     This is because the Container Manipulator is not meaningful without the Container it writes to.

     Note: Container Manipulators that read from a Container follow the rule that all of its ancestors are copied, including the Container that it reads from.
• When you make a change to a referenced component or any of its ancestors, your changes are reflected in every workspace in which it is used, including in the workspace in which it was originally created.

  For example, when you add a component that becomes a new ancestor of a referenced component, this component is added in all of the workspaces that use the referenced component.

Component reference examples

The following diagram and accompanying table use an example trigger system to illustrate the rules that apply when you copy and paste a component reference.