View & Layout Editor

The View Editor and Layout Editor work together to define the user interface of a Kitto^x application. Views define what data is shown and how it behaves; layouts define where fields are positioned in forms.

View Editor

Editor layout

When you double-click a view in the project tree, KIDE^x opens it in the editor panel:

The tree shows the complete view structure:

• Type — Data (for data-bound views) or Tree (for menu views)
• Controller — the controller type (List, Form, BorderPanel, TabPanel, etc.)
• MainTable — the primary data model and its field selection
• Fields — which model fields to include and their view-level overrides
• DetailTables — master/detail relationships for form tabs
• Controller settings — CRUD permissions, toolbar, filters, paging, ToolViews

Read-only properties

A property that the metadata carries but the HTMX runtime does not honour yet is shown read-only rather than hidden: the value written in the YAML stays visible and can be copied, but it cannot be edited from the designer. It becomes editable again when the feature is wired up.

Creating a view manually

1. Right-click the Views node in the project tree
2. Select New View
3. Choose the view type (Data or Tree)
4. Enter a name for the YAML file
5. Use the tree editor and context menus to build the view structure

DataView wizard

For a data grid over one or more models, the DataView Wizard builds the views in one step and lets you edit them before they are saved:

1. Select one or more models in the project tree, right-click and select Create DataView…
2. The wizard builds an AutoList view for each of them and lists them on the left; the tree editor on the right edits the one selected, before anything is written
3. Press F2 on a view to rename it — the name becomes the file name, and a name already taken is shown in red
4. Click Finish — KIDE^x writes one YAML file per view in the Views directory

Each view comes out as the AutoList builder makes it: Type: Data, Controller: List, a MainTable referencing the model with every field as a column, one detail table per detail reference, and a FreeSearch filter over the text fields.

View wizard

The DataView wizard covers one of the seven view builders. The View Wizard covers them all: the grid and the form, the grouped grid, the template panel, the chart, the calendar and the map. It opens from three places:

• right-click a model in the project tree and select Create View with the wizard…, with that model already chosen
• right-click the Views folder and select New View from a Model…
• the Metadata > View Wizard… menu

It has three pages:

1. Model and type. Pick the model — the box above the list filters it — and the type of view. Each type says what it produces and what it needs beyond the model.
2. Options. What that builder understands, and nothing else: the grouping field for a grouped grid, the label and value fields for a chart, the date fields for a calendar, the address fields for a map, the template for a template panel. The grid and the form have no options of their own. The view name is optional: left empty, the builder names the view itself.
3. Preview. The YAML that will be written, exactly as it will be written, with the resolved name and the target path. A name already taken is reported here and Finish stays disabled until you go back and change it.

The wizard, the MCP tools and View: Build agree

Each page calls the same headless generator the view_*_create tools of MCP-KittoX call, which in turn calls the framework's own view builder. So the wizard, an agent and a runtime View: Build Auto… expression all produce the same view — the shape is decided in one place, and the preview page shows it before anything is written.

What the wizard deliberately does not ask for: the subnodes no builder carries (EnableMenu and the ShowCount texts of a grouped grid — write them on the view afterwards), the Google Maps API key (it belongs to the application, in Config.yaml), and the template file of a template panel (it is a resource, and goes in Resources).

Layout Editor

Layouts control how fields are arranged in form dialogs. Without a layout, fields are stacked vertically. With a layout, you can organize fields in rows, fieldsets, and multi-page tabs.

Editor layout

Layout files are stored in Metadata/Views/Layouts/ and are named by convention: {ViewName}_Form.yaml for form layouts, {ViewName}_Grid.yaml for grid column layouts.

Layout containers

The context menu for layout nodes offers these container types:

Container	Description
Field	A single field reference (by name from the model)
Row	Horizontal row — child fields are placed side by side
FieldSet	A bordered group with optional title, collapsible
Spacer	Empty space between fields
PageBreak	Starts a new tab page in the form dialog

Example layout structure:

Field: DESCRIPTION
  CharWidth: 70
FieldSet:
  Title: Details
  Row:
    Field: PHASE
    Field: EMPLOYEE
    Field: ROLE
FieldSet:
  Title: Timing
  Row:
    Field: ACTIVITY_DATE
    Field: START_TIME
    Field: END_TIME
    Field: DURATION
    Field: STATUS

Layout preview

KIDE^x can show a live preview of a layout without compiling or launching the application: it renders the layout with the real Kitto^x engine in an embedded browser. Because a layout has no rendering of its own, KIDE^x previews the first view that uses the layout (resolved from the explicit Controller/Form|Grid/Layout node or the {ViewName}_Form / {ViewName}_Grid convention).

Open a Layout in the editor and use the Preview command (toolbar, the View menu, or the layout node's context menu). Editing the layout and saving triggers an automatic reload of the preview.

See Live Preview for the full description (device emulation, live-reload, and how views and layouts are previewed).

Grid layouts

Grid layouts ({ViewName}_Grid.yaml) control which columns appear in the grid and their order. They are simpler than form layouts — just a flat list of field names:

Field: DESCRIPTION
Field: ACTIVITY_DATE
Field: EMPLOYEE
Field: STATUS
Field: DURATION

View validation

When saving a view, KIDE^x checks for:

• References to fields not present in the model
• Invalid controller names
• Missing required nodes (e.g. MainTable for Data views)
• Layout fields that don't match the view's field list

Errors appear in the log panel with line numbers and descriptions.