An editor interface represents the look and feel of content type fields in the web app. They are tightly coupled to a content type and define which widget is rendered for the content type's fields.

For example, the following content type describes a typical blog post data structure. It has a title, a body, and a category that can be either "General", "iOS" or "Android".

{
  "fields": [
    { "id": "title", "name": "Title", "type": "Symbol" },
    { "id": "body", "name": "Body", "type": "Text" },
    {
      "id": "category", "name": "Category", "type": "Symbol",
      "validations": [{ "in": ["General", "iOS", "Android"] }]
    }
  ]
}

An editor interface could, for example, define that the title field should be rendered as an input field (the widget id is singleLine). It could then define that the body should be a normal text area (the widget id is multipleLine), and that the category should be rendered as a dropdown field (the widget id is dropdown).

The editor interface would look like this:

{
  "controls": [
    { "fieldId": "title", "widgetId": "singleLine" },
    { "fieldId": "body", "widgetId": "multipleLine" },
    { "fieldId": "category", "widgetId": "dropdown" }
  ]
}

There are sets of applicable widgets per content type field type:

Settings

You can pass custom settings to a control that change the behavior or presentation of a widget.

The entry for a field of type Boolean, for example, would look like this.

{
  "fieldId": "isFeatured",
  "widgetId": "boolean",
  "settings": {
    "helpText": "Feature the post on homepage?",
    "trueLabel": "yes",
    "falseLabel": "no",
  }
}

If present, the settings object of a control must be an object. All widgets accept the helpText setting and use it to render extra information with the widget. Other settings are widget specific.