Template Parameters

As a result of the primary use-case of templates being the ease of maintaining repeated user interface elements, proper use of parameters is paramount. Parameters are used to allow each template instance to reference different data elements of repeated data structures.

This is very similar to the concept of Parameterized Windows. In that case, any custom property on the root container of the window can be used as a parameter, passed into the window when it is opened. Templates take this idea one step further.

Parameters and Internal Properties

When you open the Custom Properties customizer for a template master, you'll notice it is different than for all other components. Two kinds of custom properties are allowed: parameter properties and internal properties.

A parameter property will appear on each template instance, allowing each template instance to be configured differently. Commonly, this will be some sort of indirection. For example, if your template is for representing motors, then you might have MotorNumber as a parameter property. Then you could use that property as an indirection variable in other bindings within the template.

Parameter properties are not bindable from within the template master design. When you use the template to create a template instance, the property will become bindable. This ensures that the property only has a single binding configured for it.

An internal property cannot be used as a parameter. It will show up when designing the template master, but it will not show up on the template instances. Internal properties are bindable from within the template master design. These properties are intended to be used for the internal workings of the template.

Indirection and UDT Tags

There are two primary ways to achieve indirection when using templates. Let's continue to use the example of a motor. Your system has many motors in it, and your template is used to display the status of the motors and control the motor's running mode. The goal is to be able to drop instances of the template onto your windows, and configure them in a single step to point to the correct motor's tags.

If the tags representing the datapoints of each motor are arranged in an orderly fashion in folders or with a consistent naming convention, you can use standard indirection to configure your template. You'd add a parameter such as MotorNum to the template. Then you'd configure the contents of the template using indirect tag binding, where the value of MotorNum is used for the indirection.

If your motors are represented by a custom tag data type, then you can save some effort and use a property of that tag type directly. Make your indirection property the same type as your custom data type. Then you can use simple property bindings to configure the components inside your template. When you create a template instance, you can simply bind that property directly to the correct Motor tag, and all of the sub-tags of motor will be correctly mapped through the property bindings.

The Drop Target Parameter

You may choose one of your parameters as the drop target. This lets you drop tags onto your template instances to facilitate even quicker binding. For example, let's say that you have a parameter that is an integer and you've made it the drop target. If you drop an integer tag onto a window, your template will appear in the list of components that it suggests you make. Choosing your template will create a template instance and bind that parameter to the tag.

This also works for UDT tags. Lets say you have a custom data type called "Motor" and a template with a Motor-typed parameter set as the drop target. If you drop a motor tag onto a window, it'll create an instance of your template automatically. If you have more than one template configured with Motor drop targets, then you'll have to choose which template to use.