Server Bindings
Most bindings encountered in Iotellect are of one of two types: frontend or backend. The backend (or server) bindings define relations between data items (such as variables, functions, and events) of different server contexts. This type of binding mechanism can be found in models.
Frontend bindings extend the server bindings syntax by adding the possibility to reference dashboards UI components.
In other words, the “engine” of Iotellect dashboards and models is constructed of server context bindings. Every binding is evaluated at different points during dashboard or model operation, and the evaluation results are used to modify context data.
Server bindings' main parameters are:
Binding Activator, Condition, and Flags define when a binding is processed. Processing may occur on sever or dashboard startup, a button click, changes in a variable or properties of dashboard components, an appearance of a new event instance, etc.
The binding Expression is evaluated every time a binding is activated. The evaluation value is what will be the result of binding processing. A binding expression may use values from the properties of dashboard components or various data from server contexts. The evaluation result is sent to the binding target.
Binding Target is a reference defining where the result of the evaluation of binding expression will be written to, i.e. which property of the GUI component or what context data will be changed.
Binding Activation
Activation of server bindings is controlled by:
On Startup parameter - when it is enabled, the binding is processed every time the binding set is started. In case of model bindings, it’s Iotellect Server startup or model configuration change. For dashboard bindings, it’s a moment when a user opens a dashboard instance in a browser.
On Event parameter - when enabled and an Activator is specified, the binding is processed whenever there's a change of the property the activator refers to. If the Activator refers to an event, the binding will be processed when the event is fired. If the Activator refers to a variable, the binding is processed when the value of the variable is altered. If there is no activator specified and the binding's Expression includes references pointing to one or more variables, a change of any of these variables will cause the binding to execute.
Activator is a reference that points to some context event or property that triggers the processing of the binding. The Activator parameter is available only when the On Event flag is enabled.
Periodically parameter - if this parameter is enabled, the binding will be processed at regular intervals specified by the Period setting.
Condition is an Iotellect Expression that is evaluated first after binding activation. If the result of the expression evaluation is false, the binding execution is skipped.
Queue is the name of the binding target processing queue. The bindings engine guarantees that the targets of bindings that belong to the same queue will be accessed in the same order the bindings were executed. Queue parameter is not supported in some binding evaluation environments, e.g. in model bindings.
Binding Activation Order
Because bindings are executed concurrently, the execution order of bindings is not fixed. If two bindings are activated at the same time, it cannot be determined which one will be executed first. It is important to consider this when creating bindings that are dependent on the results of other bindings.
For example, one binding updates a context property. Another binding is activated by an event and executes a function if the context property value is updated. Two bindings are activated at the same time. If the binding that updates the property is executed first, then the second binding will call the function. If the binding that calls the function is executed first, it will not call its function. As a result, the event that should have activated this binding will be ignored.
To avoid unpredictable behavior with bindings that depend on other bindings, make sure that you specify the correct chain of binding activators. If binding A depends on the activation of binding B, then binding A's activator must be the result of binding B's activation. For example, if binding A changes a context property, then binding B must be activated by this property, not by a separate event. This will ensure that bindings will be executed one after another in the correct order.
 | The only way to get a predictable binding execution order is to disable concurrency, e.g., by setting the binding thread pool sizes to |
| A binding configured to be activated On startup or On Event is guaranteed to be activated upon binding engine startup and each matching event respectively. However, those bindings may be reactivated in some other cases. For example dashboard and data table bindings may be re-evaluated in case of reloading a dashboard, reconnecting to the server, of navigating through the Data Table Editor’s UI. Such a reactivated binding may cause loss of user input in its Target if designed improperly. If this is not acceptable, a binding should take into account previously changed data in its Target (by referring its own Target from its Expression). The Expesssion should “merge” this previous Target data with the new data to be written to the Target. For example, the below binding will update the
|
Was this page helpful?