Bindings

AggreGate bindings

Bindings are called this way because they bind various data items to each other. When you bind something in the real world (such as a package to the roof of a car), you actually tie it tightly. That's the core meaning here – tying something tightly.

With bindings, you dynamically connect some data to other data. For example, dashboard elements may be linked to device settings stored in the server-side device snapshot.

AggreGate bindings engine works in widgets, models, classes and other modules. It helps to tie the module’s internal elements – such as UI components in a widget or class instances – to each other and formalized elements of the unified data model.

Every binding can be activated on startup, on change of value, on event or periodically. It has an expression that refers environment specific values and converts them to a single output value and a target which is a place used for storing the expression result.

Bindings are smart enough to analyze your expression and adapt. For example, if your binding says power = {voltage} * {current}, it will be automatically triggered upon changes of both current and voltage values.

AggreGate bindings engine

Example:

You have a textbox in a dialog which is grayed out. You can't write anything in it. This textbox has a checkbox next to it, saying something like "Enable this setting?". Once the checkbox is checked, the textbox magically becomes enabled, and you can write in it. This is done via the bindings – the value of the checkbox (checked or unchecked) is bound to the state of the textbox (enabled or disabled).

Configurable concurrency of bindings makes system architects able to adapt to changing conditions – some settings are right for low-resource embedded environment, while others optimize performance in a large cloud-based system.