This section covers concepts needed to add the change the configurations of your Custom View.
This is contextual object which is available through omniscope.view.context() which contains results
of any auto-queries and also about the data available to the view. This includes brushed and brushed out data
results.
It also provides you with configuration details for example, what value the user picked for a split if you have one configured.
You can think of it as a communication link between your view and rest of the application for passing and retrieving data and configuration.
The JSON below shows main sections of the context (not in correct JSON syntax as JSON below is for illustration purpose only).
{
// Name of the view
"viewName": "Custom",
// Unique id of the view auto generated by the framework
"viewInstanceId": "2-view-0-0",
// The base url which is used for requesting resources for the view
"baseUrl": "http://127.0.0.1:51111/4_ic3h26id/",
// The data config which describes the subset of data the view can see and
// provides details how to retrieve and query data for the view
"dataConfig": {
"queryApiEndpoint": "http://127.0.0.1:51111/3_ic3h26id",
"datamanagerApiEndpoint": "",
"filter": {...}
},
...
// Stores the actual choices for the different options defined in the
// manifest. In this case it is showing the RECORD_COUNT being used for
// measures.
"options": {
"items": {
"measures": {
"function": "RECORD_COUNT"
}
},
// Pane specific configuration.
"pane": {
"headerWidth": 100,
"headerHeight": 30,
"paneWidth": 100,
"paneHeight": 100,
"xHeaderPlacement": "TOP",
"yHeaderPlacement": "LEFT"
}
},
// The manifest itself associated with the view.
"manifest": {
...
},
// The results for the auto-query if enabled.
"result": {
"data": {
"schema": {
"fields": [
{
"name": "_1_measures",
"type": "NUMBER"
}
]
},
"records": [
[
50
]
]
},
// Shadow data only relevant when you have selection.
"shadowData": null,
// Describes the mappings of how your configuration map to
// to the results. For example, in this case we are saying
// that measures result is stored in array index 0 in the result.data.records.
"mappings": {
"measures": 0
}
},
// Only relevant if auto-paning is turned on, it describes the coordinates within the pane grid.
"pane": {
"x": "0",
"y": "0"
}
// If you have variables in your file. The current variable values will be available here.
// NOTE: The values are the underlying values, you would need to do your own formatting if necessary.
// The name is case-sensitive variable name corresponding to the value.
"variables": {
"my var": 25000,
"category variable": 0
}
...
}
For more information see ViewApiContext.
A view can have any number of options both which the user can configure and others which are not configurable but are available for your view.
The view options are defined in the manifest.json in the items map where the key to the map is a unique identifier for the option. This identifier is then used for both storing and retrieval.
For example, to define a Split you would do something like:
...
"split": {
"displayName": "Split by",
"type": "GROUPING",
"list": true
},
...
"structure": {
...
"toolbar": [ "split" ...]
...
}
In the example above split is the internal name and is used for both adding it to the toolbar
as is the case in the example above, and the name you have to use to retrieve the option.
When a user configures an option in your view the resulting value is stored in the in the options of the ViewApiContext.
The key in the map is the same internal name you used in the manifest to define the option and the value being the actual user stored value.
For example, to retrieve the split option you would do:
omniscope.view.context().options.items.split
OR
omniscope.view.context().options.items.["split"]
Visokio have standardise naming for different kind of types in regards to the internal key in the options:
Measure option is called “measures”, unless you have more than one then you would name any subsequent measure options be called appropriately i.e. measure_xxx.
Split option is called “split”.
Stack option is called “stack”.
Pane X and Pane Y are called “paneX” and “paneY” respectively.
The reason for this is to allow your settings be ported across between different views. For example, if your view has an option called “split” as it’s internal name, and you then switch your view to say Pie view or a different view which also has “split” configuration, then your settings will automatically will be ported across and vice versa.