A schema describes the acceptable values for a parameter. It is written in JSON and inspired by JSON schema. In addition, the schema describes the form that will be displayed when adding or editing a setting associating a value to target variable.
By default, when creating a parameter with ComodIT’s web interface (see this example), you have to choose between 4 base types:
These types are in fact represented by a very simple schema containing the single field type, for example:
{"type":"string"}
Type field may have one of the following values:
The first 4 values are associated to above base types. ‘array’ type describes a list of values and ‘object’ type is used to represent a key-value map.
The value of ‘type’ field might require additional fields. With ‘array’ type, an additional ‘items’ field is required. The value of this field is another schema describing acceptable values for the items of the array. For example, a parameter whose value must be an array of integers has the following schema:
{
"type": "array",
"items": {
"type": "integer"
}
}
An acceptable value is then [1, 2, 3]
.
‘object’ type requires field ‘properties’ which describes the fields of the object. The value of this field is a map whose keys are field names and values schemas describing acceptable values of the object’s fields. For instance, a parameter whose value must be an object with 3 fields a, b and c whose values are respectively an integer, a boolean and a string has the following schema:
{
"type": "object",
"properties": {
"a": {
"type": "integer"
},
"b": {
"type": "boolean"
},
"c": {
"type": "string"
}
}
}
An acceptable value is then {"a": 1, "b": true, "c": "hello"}
.
Optional additional fields may be used in a schema. These have 2 main purposes: enforce additional constraints on value or impact presentation in UI. Constraints are both verified client and server side. Note that constraints may also impact UI.
The following schema describes the repositories that may be defined during the kickstart installation of a CentOS distribution. It is actually an array, each element (here, an object) representing a repository. Each repository is defined by a name, a base URL or a mirror list, and a flag indicating if a release package has to be installed.
{
"type": "array",
"items": {
"type": "object",
"properties": {
"mirror_list": {
"description": "Mirror list URL",
"type": "string",
"pretty": "Mirror List"
},
"name": {
"description": "The name of the repository",
"required": true,
"type": "string",
"pretty": "Name",
"index": true
},
"release": {
"default": false,
"description": "If true, install package x-release where x is the name of the repository",
"required": true,
"type": "boolean",
"pretty": "Release"
},
"base_url": {
"description": "Repository base URL",
"type": "string",
"pretty": "Base URL"
}
}
}
}
An acceptable value for above schema is as follows:
[{
"mirror_list": "https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=x86_64",
"name": "epel",
"release": true
}, {
"mirror_list": "http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=updates",
"name": "updates",
"release": false
}, {
"name": "comodit",
"base_url": "http://dl.comodit.com/pub/centos/6/x86_64/",
"release": true
}]
Finally, this value is displayed as shown in the following figure in the UI.
Left-side column allows to select a particular element of the array. Values of ‘name’ field are used to identify the elements thanks to ‘index’ flag. Values of ‘pretty’ fields are used the identify the fields in right-side panel. A red start implied by ‘required’ flag signals that field ‘name’ must be completed in order to validate value. Finally, when clicking on an ‘info’ icon, the text of ‘description’ field is displayed.
2016 © ComodIT. All Rights Reserved. Privacy Policy | Terms of Service