adapt-authoring-jsonschema 0.0.1 → 1.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,194 +1,194 @@
1
- # Writing a schema
2
-
3
- This page outlines the various elements of an Adapt data schema, and gives tips on how to start writing your own schemas. If you're new to schemas, head over to [this page](/introduction-to-schemas), which goes over the basics.
4
-
5
- > For some specific schema examples, see [this page](/schema-examples).
6
-
7
- ## Quick links
8
- - [Defining a schema](#defining-a-schema)
9
- - [Defining schema inheritance](#defining-schema-inheritance)
10
- - [Custom schema keywords](#custom-schema-keywords)
11
- - [Custom Adapt properties](#custom-adapt-properties)
12
- - [Custom Backbone Forms properties](#custom-backbone-forms-properties)
13
-
14
- ## Defining schema inheritance
15
-
16
- You may find when defining your schemas that you want to extend or modify existing schemas, or split up your schemas in such a way as you can share properties across multiple schemas. For this purpose, you can use the `$merge` and `$patch` keywords.
17
-
18
- The main difference between merge and patch schemas is how they're accessed:
19
- - `$merge` schemas are considered 'complete' schemas, and are accessed directly (e.g. the UI will request the MCQ schema by name when rendering the MCQ form page)
20
- - `$patch` schemas are not considered 'complete' schemas, but rather are 'attached' to another schema when that schema is requested (e.g. the UI will request the `course` schema which will include the relevant extension `$patch` schemas).
21
-
22
- ### `$merge` schemas
23
-
24
- Merge schemas are useful when you have a schema which needs to directly inherit from another existing schema. As an example, all Adapt framework content schemas extend from a base `content` schema, which defines the basic attributes such as `title` and `body`.
25
-
26
- Every `$merge` schema must define the base schema it inherits from (as a `source` attribute), and any additional properties (nested under a `with` attribute). For example:
27
-
28
- ```
29
- {
30
- "$anchor": "example-schema",
31
- "$schema": "https://json-schema.org/draft/2020-12/schema",
32
- "type": "object",
33
- "$merge": {
34
- "source": {
35
- "$ref": "base-schema"
36
- }
37
- "with": {
38
- "properties": {
39
- "myAttribute": {
40
- "type": "string"
41
- }
42
- }
43
- }
44
- }
45
- }
46
- ```
47
-
48
- ### `$patch` schemas
49
-
50
- `$patch` schemas are useful when looking to augment an existing schema with extra attributes or override existing schema properties (as an example, many Adapt framework extensions will define their own `$patch`schema for the `course` schema which will define extra `_globals` properties specific to that extension).
51
-
52
- `$patch` schemas are almost identical to `$merge` schemas, with the only difference being that the `$merge` is replaced with the `$patch` keyword:
53
-
54
- ```
55
- {
56
- "$anchor": "example-schema",
57
- "$schema": "https://json-schema.org/draft/2020-12/schema",
58
- "type": "object",
59
- "$patch": {
60
- "source": {
61
- "$ref": "base-schema"
62
- }
63
- "with": {
64
- "properties": {
65
- "myAttribute": {
66
- "type": "string"
67
- }
68
- }
69
- }
70
- }
71
- }
72
- ```
73
-
74
- ## Custom schema keywords
75
-
76
- In addition to the standard keywords defined in the JSON schema specification, the Adapt authoring tool jsonschema module defines a number of extra custom keywords which add extra convenient functionality when validating incoming data.
77
-
78
- The following custom keywords are available:
79
-
80
- ### `isDate`
81
- This keyword will parse any string value into a valid JavaScript Date.
82
-
83
- #### Example
84
- ```
85
- "myDateAttribute": {
86
- "type": "string",
87
- "isDate": true
88
- }
89
- ```
90
-
91
- ### `isDirectory`
92
- This keyword will resolve any path values using a number of default directory values. This is very useful when making use of the existing app directories (e.g. you want to store data in the app's temp folder). The following are supported values:
93
- - `$ROOT` will resolve to the main app root folder
94
- - `$DATA` will resolve to the app's data folder
95
- - `$TEMP` will resolve to the app's temp folder
96
-
97
- #### Example
98
- ```
99
- "myDirectoryAttribute": {
100
- "type": "string",
101
- "isDirectory": true,
102
- "default": "$TEMP/myfolder" // will be replace $TEMP with the correct path to the temp folder
103
- }
104
- ```
105
-
106
- ### `isInternal`
107
- This keyword will ensure that the attribute is **not** returned when a web API request is made. This is useful for restricting sensitive information like passwords. Note that this keyword only applies to the web APIs, and not when accessing data programatically.
108
-
109
- #### Example
110
- ```
111
- "myInternalAttribute": {
112
- "type": "string",
113
- "isInternal": true
114
- }
115
- ```
116
-
117
- ### `isReadOnly`
118
- This keyword will ensures that the attribute is **not** modified when a web API request is made. Note that this keyword only applies to the web APIs, and not when accessing data programatically.
119
-
120
- #### Example
121
- ```
122
- "myReadOnlyAttribute": {
123
- "type": "string",
124
- "isReadOnly": true
125
- }
126
- ```
127
-
128
- ### `isTimeMs`
129
- This keyword is very useful when defining time values, as it allows a human-readable input value to be automatically converted into milliseconds.
130
-
131
- #### Example
132
- ```
133
- "myTimeAttribute": {
134
- "type": "string",
135
- "isTimeMs": true,
136
- "default": "7d" // will be converted to the equivalent of 7 days in milliseconds (604800000)
137
- }
138
- ```
139
-
140
- ## Custom Adapt properties
141
-
142
- The `_adapt` keyword is used to group schema properties which are non-standard to the JSON schema specification and related to various Adapt-specific features.
143
-
144
- Property | Type | Description
145
- --- | --- | ---
146
- `editorOnly` | `Boolean` | Determines whether the attribute should be included in output JSON
147
- `isSetting` | `Boolean` | Attribute will appear in the ‘Settings’ section of the form
148
- `translatable` | `Boolean` | Whether the attribute is a language-specific string for translation
149
-
150
- ### Example
151
- ```
152
- "myAttribute": {
153
- "type": "string",
154
- "_adapt": {
155
- "editorOnly": true,
156
- "translatable": true
157
- }
158
- }
159
- ```
160
-
161
- ## Custom Backbone forms properties
162
-
163
- The Adapt authoring tool uses the [Backbone Forms](https://github.com/powmedia/backbone-forms) library to render forms from the data schemas into a user-friendly HTML form. The `_backboneForms` keyword is used to group schema properties which apply to Backbone Forms.
164
-
165
- Property | Type | Description
166
- --- | --- | ---
167
- `type` | `String` | Override the type of Backbone Forms input to be used (by default, the type will be inferred from the schema property's type value). Accepted types: `Asset`, `Text`, `Number`, `Password`, `TextArea`, `Checkbox`, `Checkboxes`, `Select`, `Radio`, `Object`, `Date`, `DateTime`, `List`. See the [Backbone Forms docs](https://github.com/powmedia/backbone-forms#schema-definition) for more information.
168
- `showInUi` | `Boolean` | Determines whether the attribute will be rendered in forms
169
- `media` | `String` | When using a `type` of `Asset`, you can also restrict the AAT UI to only show assets of a specific type. The AAT stores the asset type based in its [MIME type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types) (e.g. files with a MIME type of `image/png` and `image/jpeg` would both have a type of `image`).
170
- `editorAttrs` | `Object` | Extra options passed to the Backbone Forms input. See the [Backbone Forms docs](https://github.com/powmedia/backbone-forms#schema-definition) for more information.
171
-
172
- > The Adapt authoring tool will attempt to infer the type of a form input using the `type` value in the schema. In most cases this will suffice, so check that you definitely need to override the default behaviour before defining additional `_backboneForms` properties.
173
-
174
- ### Example
175
-
176
- ```
177
- "myAttribute": {
178
- "type": "string",
179
- "_backboneForms": {
180
- "type": "Asset",
181
- "showInUi": false,
182
- "media": "image"
183
- }
184
- }
185
- ```
186
-
187
- In many cases, you'll only want to customise the type of an input. If this is the case, the `_backboneForms` property can also be a string value, e.g.
188
-
189
- ```
190
- "myAttribute": {
191
- "type": "string",
192
- "_backboneForms": "Number"
193
- }
1
+ # Writing a schema
2
+
3
+ This page outlines the various elements of an Adapt data schema, and gives tips on how to start writing your own schemas. If you're new to schemas, head over to [this page](/introduction-to-schemas), which goes over the basics.
4
+
5
+ > For some specific schema examples, see [this page](/schema-examples).
6
+
7
+ ## Quick links
8
+ - [Defining a schema](#defining-a-schema)
9
+ - [Defining schema inheritance](#defining-schema-inheritance)
10
+ - [Custom schema keywords](#custom-schema-keywords)
11
+ - [Custom Adapt properties](#custom-adapt-properties)
12
+ - [Custom Backbone Forms properties](#custom-backbone-forms-properties)
13
+
14
+ ## Defining schema inheritance
15
+
16
+ You may find when defining your schemas that you want to extend or modify existing schemas, or split up your schemas in such a way as you can share properties across multiple schemas. For this purpose, you can use the `$merge` and `$patch` keywords.
17
+
18
+ The main difference between merge and patch schemas is how they're accessed:
19
+ - `$merge` schemas are considered 'complete' schemas, and are accessed directly (e.g. the UI will request the MCQ schema by name when rendering the MCQ form page)
20
+ - `$patch` schemas are not considered 'complete' schemas, but rather are 'attached' to another schema when that schema is requested (e.g. the UI will request the `course` schema which will include the relevant extension `$patch` schemas).
21
+
22
+ ### `$merge` schemas
23
+
24
+ Merge schemas are useful when you have a schema which needs to directly inherit from another existing schema. As an example, all Adapt framework content schemas extend from a base `content` schema, which defines the basic attributes such as `title` and `body`.
25
+
26
+ Every `$merge` schema must define the base schema it inherits from (as a `source` attribute), and any additional properties (nested under a `with` attribute). For example:
27
+
28
+ ```
29
+ {
30
+ "$anchor": "example-schema",
31
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
32
+ "type": "object",
33
+ "$merge": {
34
+ "source": {
35
+ "$ref": "base-schema"
36
+ }
37
+ "with": {
38
+ "properties": {
39
+ "myAttribute": {
40
+ "type": "string"
41
+ }
42
+ }
43
+ }
44
+ }
45
+ }
46
+ ```
47
+
48
+ ### `$patch` schemas
49
+
50
+ `$patch` schemas are useful when looking to augment an existing schema with extra attributes or override existing schema properties (as an example, many Adapt framework extensions will define their own `$patch`schema for the `course` schema which will define extra `_globals` properties specific to that extension).
51
+
52
+ `$patch` schemas are almost identical to `$merge` schemas, with the only difference being that the `$merge` is replaced with the `$patch` keyword:
53
+
54
+ ```
55
+ {
56
+ "$anchor": "example-schema",
57
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
58
+ "type": "object",
59
+ "$patch": {
60
+ "source": {
61
+ "$ref": "base-schema"
62
+ }
63
+ "with": {
64
+ "properties": {
65
+ "myAttribute": {
66
+ "type": "string"
67
+ }
68
+ }
69
+ }
70
+ }
71
+ }
72
+ ```
73
+
74
+ ## Custom schema keywords
75
+
76
+ In addition to the standard keywords defined in the JSON schema specification, the Adapt authoring tool jsonschema module defines a number of extra custom keywords which add extra convenient functionality when validating incoming data.
77
+
78
+ The following custom keywords are available:
79
+
80
+ ### `isDate`
81
+ This keyword will parse any string value into a valid JavaScript Date.
82
+
83
+ #### Example
84
+ ```
85
+ "myDateAttribute": {
86
+ "type": "string",
87
+ "isDate": true
88
+ }
89
+ ```
90
+
91
+ ### `isDirectory`
92
+ This keyword will resolve any path values using a number of default directory values. This is very useful when making use of the existing app directories (e.g. you want to store data in the app's temp folder). The following are supported values:
93
+ - `$ROOT` will resolve to the main app root folder
94
+ - `$DATA` will resolve to the app's data folder
95
+ - `$TEMP` will resolve to the app's temp folder
96
+
97
+ #### Example
98
+ ```
99
+ "myDirectoryAttribute": {
100
+ "type": "string",
101
+ "isDirectory": true,
102
+ "default": "$TEMP/myfolder" // will be replace $TEMP with the correct path to the temp folder
103
+ }
104
+ ```
105
+
106
+ ### `isInternal`
107
+ This keyword will ensure that the attribute is **not** returned when a web API request is made. This is useful for restricting sensitive information like passwords. Note that this keyword only applies to the web APIs, and not when accessing data programatically.
108
+
109
+ #### Example
110
+ ```
111
+ "myInternalAttribute": {
112
+ "type": "string",
113
+ "isInternal": true
114
+ }
115
+ ```
116
+
117
+ ### `isReadOnly`
118
+ This keyword will ensures that the attribute is **not** modified when a web API request is made. Note that this keyword only applies to the web APIs, and not when accessing data programatically.
119
+
120
+ #### Example
121
+ ```
122
+ "myReadOnlyAttribute": {
123
+ "type": "string",
124
+ "isReadOnly": true
125
+ }
126
+ ```
127
+
128
+ ### `isTimeMs`
129
+ This keyword is very useful when defining time values, as it allows a human-readable input value to be automatically converted into milliseconds.
130
+
131
+ #### Example
132
+ ```
133
+ "myTimeAttribute": {
134
+ "type": "string",
135
+ "isTimeMs": true,
136
+ "default": "7d" // will be converted to the equivalent of 7 days in milliseconds (604800000)
137
+ }
138
+ ```
139
+
140
+ ## Custom Adapt properties
141
+
142
+ The `_adapt` keyword is used to group schema properties which are non-standard to the JSON schema specification and related to various Adapt-specific features.
143
+
144
+ Property | Type | Description
145
+ --- | --- | ---
146
+ `editorOnly` | `Boolean` | Determines whether the attribute should be included in output JSON
147
+ `isSetting` | `Boolean` | Attribute will appear in the ‘Settings’ section of the form
148
+ `translatable` | `Boolean` | Whether the attribute is a language-specific string for translation
149
+
150
+ ### Example
151
+ ```
152
+ "myAttribute": {
153
+ "type": "string",
154
+ "_adapt": {
155
+ "editorOnly": true,
156
+ "translatable": true
157
+ }
158
+ }
159
+ ```
160
+
161
+ ## Custom Backbone forms properties
162
+
163
+ The Adapt authoring tool uses the [Backbone Forms](https://github.com/powmedia/backbone-forms) library to render forms from the data schemas into a user-friendly HTML form. The `_backboneForms` keyword is used to group schema properties which apply to Backbone Forms.
164
+
165
+ Property | Type | Description
166
+ --- | --- | ---
167
+ `type` | `String` | Override the type of Backbone Forms input to be used (by default, the type will be inferred from the schema property's type value). Accepted types: `Asset`, `Text`, `Number`, `Password`, `TextArea`, `Checkbox`, `Checkboxes`, `Select`, `Radio`, `Object`, `Date`, `DateTime`, `List`. See the [Backbone Forms docs](https://github.com/powmedia/backbone-forms#schema-definition) for more information.
168
+ `showInUi` | `Boolean` | Determines whether the attribute will be rendered in forms
169
+ `media` | `String` | When using a `type` of `Asset`, you can also restrict the AAT UI to only show assets of a specific type. The AAT stores the asset type based in its [MIME type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types) (e.g. files with a MIME type of `image/png` and `image/jpeg` would both have a type of `image`).
170
+ `editorAttrs` | `Object` | Extra options passed to the Backbone Forms input. See the [Backbone Forms docs](https://github.com/powmedia/backbone-forms#schema-definition) for more information.
171
+
172
+ > The Adapt authoring tool will attempt to infer the type of a form input using the `type` value in the schema. In most cases this will suffice, so check that you definitely need to override the default behaviour before defining additional `_backboneForms` properties.
173
+
174
+ ### Example
175
+
176
+ ```
177
+ "myAttribute": {
178
+ "type": "string",
179
+ "_backboneForms": {
180
+ "type": "Asset",
181
+ "showInUi": false,
182
+ "media": "image"
183
+ }
184
+ }
185
+ ```
186
+
187
+ In many cases, you'll only want to customise the type of an input. If this is the case, the `_backboneForms` property can also be a string value, e.g.
188
+
189
+ ```
190
+ "myAttribute": {
191
+ "type": "string",
192
+ "_backboneForms": "Number"
193
+ }
194
194
  ```
@@ -1,52 +1,52 @@
1
- {
2
- "INVALID_SCHEMA": {
3
- "data": {
4
- "errors": "all validation errors",
5
- "schemaName": "Schema name"
6
- },
7
- "description": "Invalid schema",
8
- "statusCode": 400
9
- },
10
- "MISSING_SCHEMA": {
11
- "data": {
12
- "schemaName": "Schema name"
13
- },
14
- "description": "Schema is not registered in the cache",
15
- "statusCode": 500
16
- },
17
- "MISSING_SCHEMA_NAME": {
18
- "description": "Schema name is not defined",
19
- "statusCode": 400
20
- },
21
- "MODIFY_PROTECTED_ATTR": {
22
- "data": {
23
- "attribute": "The protected attribute"
24
- },
25
- "description": "Attempted to modify a protected data attribute",
26
- "statusCode": 400
27
- },
28
- "SCHEMA_EXISTS": {
29
- "data": {
30
- "filepath": "File path to the schema",
31
- "schemaName": "Schema name"
32
- },
33
- "description": "A schema already exists with the specified name",
34
- "statusCode": 400
35
- },
36
- "SCHEMA_LOAD_FAILED": {
37
- "data": {
38
- "schemaName": "Schema name"
39
- },
40
- "description": "Failed to load a JSON schema",
41
- "statusCode": 500
42
- },
43
- "VALIDATION_FAILED": {
44
- "data": {
45
- "data": "the data failing validation",
46
- "errors": "all validation errors",
47
- "schemaName": "Schema name"
48
- },
49
- "description": "Data validation failed",
50
- "statusCode": 400
51
- }
52
- }
1
+ {
2
+ "INVALID_SCHEMA": {
3
+ "data": {
4
+ "errors": "all validation errors",
5
+ "schemaName": "Schema name"
6
+ },
7
+ "description": "Invalid schema",
8
+ "statusCode": 400
9
+ },
10
+ "MISSING_SCHEMA": {
11
+ "data": {
12
+ "schemaName": "Schema name"
13
+ },
14
+ "description": "Schema is not registered in the cache",
15
+ "statusCode": 500
16
+ },
17
+ "MISSING_SCHEMA_NAME": {
18
+ "description": "Schema name is not defined",
19
+ "statusCode": 400
20
+ },
21
+ "MODIFY_PROTECTED_ATTR": {
22
+ "data": {
23
+ "attribute": "The protected attribute"
24
+ },
25
+ "description": "Attempted to modify a protected data attribute",
26
+ "statusCode": 400
27
+ },
28
+ "SCHEMA_EXISTS": {
29
+ "data": {
30
+ "filepath": "File path to the schema",
31
+ "schemaName": "Schema name"
32
+ },
33
+ "description": "A schema already exists with the specified name",
34
+ "statusCode": 400
35
+ },
36
+ "SCHEMA_LOAD_FAILED": {
37
+ "data": {
38
+ "schemaName": "Schema name"
39
+ },
40
+ "description": "Failed to load a JSON schema",
41
+ "statusCode": 500
42
+ },
43
+ "VALIDATION_FAILED": {
44
+ "data": {
45
+ "data": "the data failing validation",
46
+ "errors": "all validation errors",
47
+ "schemaName": "Schema name"
48
+ },
49
+ "description": "Data validation failed",
50
+ "statusCode": 400
51
+ }
52
+ }
package/index.js CHANGED
@@ -1,5 +1,5 @@
1
- /**
2
- * Validation of data against JSON schemas
3
- * @namespace jsonschema
4
- */
5
- export { default } from './lib/JsonSchemaModule.js'
1
+ /**
2
+ * Validation of data against JSON schemas
3
+ * @namespace jsonschema
4
+ */
5
+ export { default } from './lib/JsonSchemaModule.js'