A Widget is a special application that may be used to control, configure and monitor different hardware devices or system components. Every widget has a graphical user interface (GUI) defined by a number of widget components and their layout. Widgets are good for building custom forms and Human-Machine Interfaces (HMI).
|
Before you begin: Widgets let you manipulate and view AggreGate data in various forms. To be effective in creating them, you should be familiar with References, Expressions and finally, Data Bindings. Please read these three topic before continuing. Once you understand these topics, you can read all about the specific ways in which bindings apply to widgets in Widget Bindings. |
Widgets are created in GUI Builder, which is a part of AggreGate Client. The core of a widget is its template -- text in XML format, containing the layout and properties of its internal components along with relations between these components and the data model, i.e. data that comes from LinkServer contexts. Every widget may be launched in different LinkServer User Interfaces, e.g. in AggreGate Client. Its appearance will depend on the specific User Interface in which it runs, but its overall structure and behaviour will be similar.
Every widget is originally created to work with contexts of a certain type. A widget is always launched by a special Launch Widget action. The Launch Widget action for a particular widget appears only in context types for which that widget was created. When the Launch Widget action is started in some context, this context becomes a default context for the running widget. The widget normally gets data from the default context, but may exchange data with any other LinkServer contexts.
Here is what a running widget may look like in AggreGate Client:
|
Widgets may be created only in AggreGate Client. Other LinkServer User Interfaces have no analogs of a GUI Builder. |
New widgets are created using the Create New Widget action of the Widgets context. This is a Drag and Drop action that accepts any context type. The action assumes that one context (the "accepted context") is selected before it starts. This accepted context has one simple use during widget creation: its type will be used as the type of context for which the new widget will be available. The Launch Widget action will be installed in all contexts of this type once the widget is created.
|
Example: If a User context is dragged and dropped on the Widgets context (i.e. selected as an "accepted" context for a Create New Widget action), the newly created widget will be suitable for use with every User context in LinkServer. Each User context will have a new Launch Widget action with a description matching that of the widget. See Launch Widget Action for details. |
Once the context type is selected, a GUI Builder starts which is used to build a widget by editing its template in a visual editor. You will now create the layout for the new widget, by adding some components to it and configuring their properties. This is also a good time to define some bindings, i.e. relations between widget components and the different variables or functions of LinkServer contexts.
You can stop editing the widget template in GUI Builder by clicking on Done or Cancel in the GUI Builder toolbar. If Cancel is clicked, action is terminated and no widget is created. If Done, the user is prompted to specify properties for the new widget. Most properties are already set by this point, but you still have to provide a name and a description for the new widget.
After that, LinkServer actually creates Widget context representing new widget. Then it finds all context of the same type as type of "accepted" context for this action and installs a Launch Widget action to them.
Widget creation is now finished. You can now launch the widget action from the contexts for which it was installed.
Administering Widgets
Two contexts are used to administer widgets: One is the general Widgets context, which serves as a container. The other is the Widget context, which holds the information for one widget. |
|
Widget properties are viewed and edited using the Configure Widget action of a Widget context.
Field Description |
Field Name |
Name. Name of the widget context. It should satisfy the context naming conventions. The name is required to refer to this widget from other parts of the system, and may not be changed once the widget is created. |
name |
Description. Textual description of the widget. This is also a description of the Widget context. |
description |
Default Context. The default context to be used when editing the widget template in GUI Builder. This setting does not affect the behaviour of running widgets. Its value is automatically set to the path of the context for which that widget was created. There's usually no need to edit it. See Default Context for a Widget for details. |
defaultContext |
Template. Text of widget template in XML format. |
template |
Context Type. This is a read-only property that shows the type of context for which the current widget may be used. It is set to the type of context for that widget was originally created. |
contextType |
These properties may be accessed through the childInfo variable.
The term default context applies to a widget in two different cases:
| • | During widget creation or editing |
| • | During widget execution |
During widget creation: When the widget template is being edited in GUI Builder, new bindings are created to bind widget components with data from contexts. When a new widget is created or edited, context paths in newly created bindings which refer to contexts below the default context are constructed relatively to the default context.
During widget execution: The default context is also defined during widget execution. This is the context from which the Launch Widget action was launched. This default context is used to resolve relative context references during widget execution. {.deviceservers:children#records} - this is a ref resolving to number of user's DS if widget is created for user context. Is uses context path relative to default context.
See widget bindings for more information.
The core of a widget is its template. The template is written in XML and stored as a property of the Widget context. It defines a widget's structure, and has two primary parts:
| • | Layout, defining the internal components of a widget, their properties and relative positions |
| • | Data bindings that define the relations between widget components and data provided by LinkServer |
In most cases, the widget template is edited in GUI Builder and editing is initiated by Edit Template action of a Widget context. But in some rare cases, the template may be manually changed (or replaced) by editing its raw text. GUI Builder also lets you export and import templates from external XML files.
Widgets are launched by a special action with a description matching the description of the widget itself. This action is called Launch Widget action.
The Launch Widget action is used to start a widget in its normal operation mode. This action is available immediately upon creation of the widget in every context of the type for which it was created. For example, if a Custom User Info Form widget is created for a User context, an action called Custom User Info Form will appear in the context of every LinkServer user. Its description is the same as that of the widget itself. Actions that are used to start widgets may be easily recognized by a 
icon.
Here is what a Launch Widget action looks like in a context menu within AggreGate Client:
For this action to be available, the user must have an effective permission level of User in two contexts:
| • | Widget context of the actual widget being launched |
| • | The context on which the widget operates, i.e. the one where Launch Action is defined |
When a widget is started in a LinkServer User Interface, a new window is created for it. The widget engine renders the contents of the widget's root panel in this window. The window's size may be defined by the Width and Height parameters of the root panel (in pixels), or calculated automatically based on the optimal sizes of the widget's internal components if Width or Height of the root panel are not specified (i.e. set to zero). An optimal size is whatever size a component has to be so it could display all of its information without hiding any or requiring the user to scroll to see it. For a label, the optimal size is however big the label has to be to show all text. For a slider, it's however long the slider has to be to fit in all ticks, etc. If only the width or the height is specified, the other dimension is optimally sized.
If a widget window is resized, its internal components are moved and resized according to their individual constraints and sizes. A widget's layout may also change on execution, when components properties are modified by bindings according to user input or changes in context data.
When a widget starts up, the widget engine processes any bindings within it which are scheduled for processing on startup. This process is called a "Bindings Processing Session". Usually, bindings executed on startup are used to read certain context values and initialize the widget components.
While working, the widget monitors changes in contexts and component properties, and processes the bindings again when such changes are detected. Also, some bindings can be configured for periodic processing.
Every processed binding may change server data, properties of widget components, or execute widget script.
See the bindings article for more information.