Page Comparison

...

Since we're just saving this to a JSON string eventually it wouldn't break anything to specify this as a "String" type. However that would necessitate that your users know each of the possible values for this field, as well as any differences between the filter value and how it's displayed to them usually. In fact it wouldn't break anything to put type Date, but it would then render a datePicker component and return strings of form "2021-03-19", so wouldn't liekly be so usefullikely be so useful. 

However there's nothing stopping you from having an "Enum" for n set Dates in a date field, say: 

"enumValues": [
	{"value": "2020-12-25", "label": "Christmas 2020"},
	{"value": "2019-12-25", "label": "Christmas 2019"},
	{"value": "2018-12-25", "label": "Christmas 2018"},
],

The point of stating all this is just to illustrate that the actual type of the underlying data isn't what you're specifying here, it's all relating to the configurable form and display.

The final part of this section is the comparators. For SimpleSearch these can be chosen from the list (although this is at present not enforced):

["==", "!=", "=~", "!~", ">", ">=", "<", "<=", "isNull", "isNotNull"]

since those are the comparators understood by KIWT style endpoints. Obviously not all of these make sense in all circumstances, but the Definition does not care, and will dutifully offer all of the comparators specified without question, even though "status <= 'abc'" is clearly nonsense.

Sort

The sort block is the simplest of the three, 

{
	"name":"endDate",
	"sortPath":"endDate",
	"sortTypes": ["asc", "desc"]
}

This simply needs the path, and whether we're offering ascending/descending options. If there is only one sortType for a single sortEntry then no options are offered to the user in the form and that single value is used instead.