...
The Dashboard will need to be serialised as a Preference. The serialisation format will be a concern of the WMC only; the Broker will handle it as an opaque preference type (X-Dashboard).
A dashboard will have one or more widgets. Each widget will associated with one preference. For the first version, the associated preferences will all be query preferences.
The serialisation format needs to encapsulate:
- Layout of the widgets, relative to one and other.
- For each widget:
- id of each widget
- position of each widget
- configuration associated with
- widget (such as widget state e.g
- CLOSED or refresh period)
- reference to the preference itself
- configuration associated with preference (e.g. for a query preference, a row limit).
For the first version, the only supported layout will be widgets organised in a single column. Layouts will be extensible to support more sophisticated layouts in future.
Serialisation Format
This initial version of a serialisation format for a 2 x 2 single column dashboard:
Code Block |
---|
id1 id3 id2 id4w1 w2 |
would look like this:
Code Block | ||
---|---|---|
| ||
{ "version": 1.0, layout: { "matrixtype": [["id1singleColumn", "id2column"],: ["id3w1", "id4w2"]], "layoutStyle": "COLUMNS_AND_ROWS" }, configurationwidgets: { "id1w1" : { "refreshPeriodtype", 30000 : "query", "staterefreshPeriod" : "OPEN"30000, /* State of the widget */ "widgetConfigurationstate" : /* Arbitrary configuration items understood by the widget */ "OPEN", "preference" : { "queryLimitid" : 50 "<preference uuid>", } "id2"configuration" : {....} } } |
Matrix is a two dimensional array, with inner arrays corresponding to each column's contents. Columns need not have the same number of entries. The lists within the matrix may not contain nulls..
Each widget may have configuration associated with it. It will be legal for configuration to be absent, in which case, defaults will apply. Configuration will be divided into configuration that may be associated with any widget (for instance, refreshPeriod or state), and configuration that associates with widgets of particular types (for instance, limit). The widget configuration's is opaque to the dashboard serialisation format. The widget configuration does not encapsulate the widget's type. To discover the type, a further REST API call will be necessary.
To illustrate the the format further, if I wanted a format like this:
Code Block |
---|
id2 id1 id3 id4 |
it would be serialised as:
Code Block | ||
---|---|---|
javascript | javascript | layout: { "matrix": [["id1"], ["id2", "id3", "id4"]], "layoutStyle": "COLUMNS_AND_ROWS" }, |
Later we can add more sophisticated layout styles if required.
For instance, to allow for dashboard layouts like this:
Code Block |
---|
id1 queryLimit" : 50 id3 id2 id4 id5 id6 |
we could serialise generically as:
Code Block | ||
---|---|---|
javascript | javascript | { "matrix": [ [["id1"]], } [["id2"], ["id3", "id4", "id5"]],} [["id6"]] ], }, "layoutStylew2" : "ROWS_OF_COLUMNS_AND_ROWS"{....} } } |
The layout
dictionary specifies the layout of the widgets on page. The type
is used by a dashboard layout factory to produce a specialised dashboard layout widget . Initially, there will be only one dashboard layout widget known as singleColumn. It arranges the widgets vertically according to widget entries within an array list. Widgets are identified by a identifier. The widget identifier will be private and will neither be understood by the end user nor the server.
The widgets
dictionary provides the configuration for each widget. The type
is used to a dashboard widget factory to produce a specialised dashboard widget. Initially, there will be be only one dashboard widget, query, which understands who to layout query results. Dashboard widget will share some common configuration such as refreshPeriod
. Preference specific configuration is supported too.