FSM Template Tags
This topic is intended for administrators and developers who use template tags in resource definitions.
A template tag uses ${ expression } syntax inside a configuration string. It evaluates against the data available when the resource definition is prepared.
Template tags can be used in resource configuration values, including nested article, element, and form values. Their result must be accepted by the target property. Template processing doesn't remove the property's type or value requirements.
A tag ends at a closing }. Nested JavaScript braces are not supported within the tag. Avoid inline object literals or function bodies that contain braces. To return an object or array, reference existing data in the available context or resource-local data, such as ${ choiceData }. The target property must still accept that result.
This topic includes the following sections:
Template Context
The following table describes the context available to template tags.
|
Context |
Purpose |
Example |
|---|---|---|
|
|
Data supplied for the current job or event. Additional properties depend on its mapping. |
|
|
|
Data supplied for the FSM Mobile user. Additional properties depend on its mapping. |
|
|
|
Resource-selection and request values supplied for this resource. Available properties depend on the request. |
|
|
Resource-local data |
Additional named data defined in the resource for use by its template tags. |
|
The options.search example applies when a request supplies a search value. It is not a value guaranteed for every resource request.
Use the names defined by the event or user mapping. A template tag doesn't make an unmapped NetSuite field available. For information about mapping, see FSM Searches and Field Mapping.
Whole Tags and Text Interpolation
When a string consists of one complete template tag, the result retains the type produced by the expression. When a tag is included within other text, its result becomes part of a string.
|
Configuration Value |
Result |
Result Type |
|---|---|---|
|
|
|
Number |
|
|
|
String |
|
|
|
Boolean |
|
|
|
String |
For example, use a whole tag when a Boolean result is required. Adding a text prefix would produce a string instead.
Handle missing context values explicitly. For a text value that should be blank when no mapped date is available, use ${ event.date || '' }. Don't rely on an unavailable property automatically becoming an empty string.
Template Data Defined in a Resource
Additional top-level properties in a resource definition can provide data for that resource's template tags. Template processing uses these properties but doesn't return the properties as additional FSM Mobile resource properties.
For example, the following resource-definition fragment uses one local label in a Heading element:
{
"headingLabel": "Inspection",
"element": {
"inspectionHeading": {
"type": "heading",
"label": "${ headingLabel }"
}
}
}
Keep resource-local template data distinct from custom element properties. Template processing uses resource-local data to prepare the resource. FSM Mobile expressions can use custom element properties. Avoid local data names that conflict with the template context.
Combining Template Tags and FSM Mobile Expressions
A template tag can supply a constant within an expression that will subsequently run in FSM Mobile. For example, the following property uses a numeric event.limit supplied by the event mapping:
{
"hidden": "reading.value > ${ event.limit }"
}
Template processing first substitutes the mapped limit. FSM Mobile then binds the resulting expression to reading.value.
Ensure that the substituted value produces valid JavaScript and has the intended type. Don't insert unescaped free-text values into an expression. Prefer a separate configured property when the value requires quoting or a more complex representation.