...
As you can see, some of the properties may be very simple fields, such as baseUrl, and some of the properties may require more complicated objects. In this case, most of the top-level properties require more detailed information, so to keep the JSON schema as efficient and flat as possible, this information is split out into a "$defs" section. Let Let's look next at the "results" property:
...
Code Block |
---|
results: { columns: [ { accessPath: "path.to.property.on.object", name: "name of property", label: "display label of field, can be overwritten", valueType: "String" }, ... ] } |
(here we've only filled in one index of the columns array, normally we'd expect more options).
The frontend can then take this information and, as part of the configuration form, offer the options to users as potential fields they can display as part of their results table. Based on the valueType, we can display the results using a formatter, like FormattedUTCDate for Dates, or ✓/✖ for Boolean values.
SimpleSearch also has similar fields for `filters` and `sort`, determining the fields which a user can define filters on, and sort on. The valueType in the filter column will be used to decide what kind of field entry the user will see in the widget creation form. For a Date they will see a FOLIO datepicker, for a String they will see a TextField etc. Finally lets look at some of the other options the SimpleSearch WidgetType gives us for the Definitions:
Code Block |
---|
"configurableProperties": {
"type": "object",
"title": "Other properties",
"description": "A collection of other properties which can be configured/made configurable",
"additionalProperties": false,
"properties": {
"urlLink": {
"$ref": "#/$defs/urlLink"
},
"numberOfRows": {
"$ref": "#/$defs/numberOfRows"
}
}
} |