...

Here you can see that urlLink is set to be configurable, whereas numberOfRows is non-configruable, and has a defaultValue. This will remove that entry on the dynamic widget form. The Type schema is set up to enforce defValue if configurable is set to false. In the case where a defValue is set and configurable is set to true this will manifest as a default value in the initial form creation.

WidgetDefinition

A WidgetDefinition ready to be accepted into the database for this type might look like the following:

{
	"type": {
		"name": "SimpleSearch",
		"version": "v1.0.0"
	},
	"version": "v1.0.0",
	"name":"ERM Agreements",
	"definition": {
		...
	}
}

(This top level shape will be shared by definitions for ALL widget types)

We will get to the definition in a moment, but first notice that we use text fields here for the "type" field. We will then use these to attempt to resolve which type this definition conforms to (If in fact after resolution we do not find the relevant type, or the "definition" field fails validation then this will error out).

We also have a "version" field. This will be used to resolve definitions in case breaking changes are made to a widgetDefinition, eg columns removed or API paths changing. The idea is that widgets created using the old version of the widgetDefinition will not immediately fail.

(The concept of what we should do here, perhaps rendering a red "attention needed" widget in place of out of date ones or a simple wanring MessageBanner, will be later determined by user use cases and stories)

The definition section is what contains the meat of the WidgetDefinition, the actual JSON conforming to the Type.