Configure values, localization, and renderers

Values cross three boundaries: JSON configuration describes presentation, backend attribute metadata describes domain data, and runtime objects carry the actual value. Keep those layers separate. A localized label does not change an API value, and a renderer hint does not change the backend attribute type.

Use this guide when choosing labels, displaying typed attributes, or deciding which input a shared editor field will render.

Localized strings

A LocalizedString is either a plain string or a partial locale map.

{
  "label": {
    "en": "Production order",
    "ru": "Производственный заказ"
  }
}

The shared resolver uses:

1. the current locale;
2. the configured application default locale;
3. an empty string when neither key exists.

Plain strings bypass locale selection. Both forms may contain _t(key) placeholders; each placeholder is resolved through the application i18n catalog.

{
  "title": "_t(application.orders) — _t(status.released)"
}

Use locale maps for domain wording maintained with the application. Use _t(...) only for keys supplied by the deployed UI catalog. Missing locale keys do not fall back to an arbitrary first entry.

Typed attribute renderers

The runtime declares these attribute data types:

Data type	Display intent	Editor control
String	short text	text, or select when listOfValue has options
Text	long text	textarea
Integer	whole number	numeric input
Double	decimal number	numeric input
Date	calendar date	date input
DateTime	date and time	datetime input
Boolean	true/false	boolean control
Binary	binary identifier/value	current text-style input
Guid	GUID	text input; blank submissions normalize to null
Color	color	color control
Interval	interval	interval control
Object	object selector/value	object control; blank submissions normalize to null
Json	JSON	JSON editor with parse validation
dtUndefine	missing/unknown type	fallback text behavior
invalid	invalid metadata	invalid display state; internal rather than a field choice

Display rendering primarily consumes AttributeData.dataType. Editor fields may set type explicitly. Custom-request Table columns may set dataType; the active custom adapters otherwise infer primitive types or fall back to String/dtUndefine depending on the data-source path.

Open the checked-in display renderer matrix

Metadata

Shared form controls resolve values in this order:

Concern	First choice	Fallback
Label	field label	attribute displayName, then attributeCaption, then attributeName
Type	field type	attribute dataType, then dtUndefine
Options	field listOfValue, including explicit null	attribute listOfValue
Comment	field comment, including explicit null	attribute comment
Regular expression	field regEx, including explicit null	attribute regEx
Default	field defaultValue	attribute defaultValue

This allows an application to override metadata deliberately. Omitting a field property means “inherit”; setting a nullable property to null means “disable the metadata value” for that field.

For action creation forms, metadata is fetched from /MetaAttributes/ForType/<metaTypeName> and, when a link is created, /MetaAttributes/ForLink/<linkName>. Link metadata is addressed with link.<attribute>. Existing-object editors can resolve metadata from the loaded object detail instead.

Lists, defaults, and validation

listOfValue is a string. It can contain:

• a JSON array of strings, numbers, booleans, or { "label", "value" } objects; or
• newline-separated values as a legacy fallback.

Any non-empty parsed option list switches the field to a Select control, regardless of its base data type.

defaultValue applies only when the editable value is currently undefined. It must not overwrite a loaded value. An object default can reference an event-selected object and one of its linked attributes.

regEx is checked for non-empty submitted values. Invalid regex syntax produces a validation error. Json strings must parse. Hidden and readonly fields are skipped by shared validation. The declared required flag is not enforced by the shared validator.

Minimal localized and typed field

{
  "attribute": "status",
  "type": "String",
  "label": {
    "en": "Status",
    "ru": "Статус"
  },
  "listOfValue": "[{\"label\":\"Draft\",\"value\":\"draft\"},{\"label\":\"Released\",\"value\":\"released\"}]",
  "defaultValue": "draft"
}

Realistic typed editor example

This editor inherits metadata for name, overrides presentation for status, groups compact fields in one row, and uses an object selection panel.

{
  "mode": "modal",
  "header": {
    "title": { "en": "Edit order", "ru": "Изменить заказ" },
    "propertyAsId": "code"
  },
  "entityType": {
    "object": { "metaTypeName": "ProductionOrder" }
  },
  "fields": [
    {
      "attribute": "name",
      "label": { "en": "Name", "ru": "Наименование" }
    },
    {
      "layout": "row",
      "fields": [
        {
          "attribute": "quantity",
          "type": "Double",
          "label": { "en": "Quantity", "ru": "Количество" }
        },
        {
          "attribute": "released",
          "type": "Boolean",
          "label": { "en": "Released", "ru": "Запущен" }
        }
      ]
    },
    {
      "attribute": "status",
      "type": "String",
      "listOfValue": "[\"draft\",\"released\",\"closed\"]",
      "defaultValue": "draft"
    },
    {
      "attribute": "product",
      "type": "Object",
      "propertyAsId": "name",
      "selectPanel": {
        "width": "44rem",
        "height": "24rem",
        "panel": {
          "id": "product-select",
          "type": "table",
          "request": { "metaTypeName": "Product" },
          "columns": [{ "attribute": "name", "label": "Product" }]
        }
      }
    }
  ]
}

Open checked-in typed editor and metadata-precedence forms

Editor fields

Editor modes, tabs, row groups, and complete form examples are documented in editors and object endpoints. This page remains the owner of field metadata precedence and renderer selection.

Object and link endpoints

Endpoint sources, idSource semantics, consumer boundaries, and create-link examples are documented in object and link endpoints.

Interactions and boundaries

• Table and Tree display values; editor surfaces also submit values. A display renderer proving a value looks correct does not prove mutation semantics.
• Date and DateTime renderers are presentation boundaries. API timezone and persistence semantics remain separate.
• editAttribute changes the submitted key while attribute continues to identify the displayed value and metadata.
• Object fields need propertyAsId only to choose display/identity text; the submitted endpoint still resolves an object selector.
• Localized labels never localize stored option values. Keep API values stable.

Limits and current drift

• required is declared but not enforced by the shared field validator.
• Binary currently uses a text-style editor control.
• Invalid or absent metadata falls back rather than validating the application configuration.
• Custom-request type handling differs between the shared request adapter and a Table-local adapter. Use explicit column dataType for predictable display.
• No renderer changes the backend schema. A mismatched explicit type can create a misleading UI or invalid payload.

Exact property reference

• LocalizedString
• editor field type
• editor field label
• editor field defaultValue
• editor field listOfValue
• editor field comment
• editor field regEx
• custom column dataType

Next tasks

• Build the complete editor and choose its endpoint
• Choose a collection request
• Configure a create or update action
• Run the typed create-and-refresh journey