@orion-front/docs

Appearance

Group panel ​

Purpose and problems it solves ​

group composes several child panels into one ordered split. Use it to build master-detail screens, dashboards, or stacked work areas while keeping each child's own configuration and behavior independent.

When to use it ​

Use group when multiple panels must be visible at the same time. Use Tabs when users should see one child at a time, or Condition when exactly one branch should be chosen from state.

Choose columns for side-by-side work and rows for vertical stacking. The words describe the child arrangement: columns produces a horizontal splitter, while rows produces a vertical splitter.

Prerequisites, inputs, and ownership ​

Every child needs a unique id and a registered panel type. Child configuration remains owned by that variant. The group only owns ordering, orientation, conditional inclusion, and each child's share of the split.

Capability map ​

  • Recursive composition: panels may contain any registered panel, including another group, tabs, or condition panel.
  • Orientation: groupLayout.type chooses side-by-side columns or stacked rows.
  • Child sizing: panelLayout.size.value and min belong to each child and are passed to the splitter as its initial and minimum relative sizes.
  • Conditional children: children with condition are filtered before rendering. This uses Group/Tabs filtering semantics, not Condition-panel branch semantics.
  • Independent behavior: requests, selection, actions, empty states, and events stay with their child panels.

Behavioral model and interactions ​

Children render in array order. Filtering happens first, so a hidden child no longer occupies a splitter pane. The remaining children are rendered recursively through the common panel renderer.

Conditions on group children support variables and objectSelected. Unconditioned children remain visible. A child marked scenario: "default" is not a fallback in a group and is filtered out; default only has branch meaning inside a condition panel. An objectSelected child may set objectTypeNames to require an exact selected-object metatype, using the same matcher as Condition and Tabs.

Sizing is local to the current group level. A size on a nested panel affects its immediate parent group, not every ancestor.

Alternatives, defaults, and precedence ​

  • groupLayout.type is required by the declared type. Runtime treats anything other than columns as the vertical rows layout; do not rely on that fallback.
  • Omitted panels produces an empty splitter.
  • Omitted child sizes let the splitter distribute available space.
  • When conditions remove children, array order among the surviving children is preserved.

Limitations and runtime drift ​

  • groupLayout.resizable is declared and adds a class, but the CSS that would disable or restyle resizing is commented out. It does not currently provide a dependable configuration contract.
  • Group does not add a title, loading state, or actions of its own.
  • Group does not coordinate child requests. Cross-panel behavior requires explicit events and request bindings.

Minimal valid configuration ​

json
{
  "id": "work-area",
  "type": "group",
  "groupLayout": {
    "type": "columns"
  },
  "panels": []
}

Realistic end-to-end scenario ​

This root keeps instructions above an object table. The first child's sizing is relative to this group only. The backend must expose the WorkOrder meta type.

json
{
  "id": "work-orders-screen",
  "type": "group",
  "groupLayout": {
    "type": "rows"
  },
  "panels": [
    {
      "id": "work-orders-help",
      "type": "message",
      "panelLayout": {
        "size": {
          "value": 20,
          "min": 12
        }
      },
      "content": {
        "heading": {
          "ru": "Рабочие заказы",
          "en": "Work orders"
        },
        "text": {
          "ru": "Выберите строку, чтобы продолжить работу.",
          "en": "Select a row to continue."
        }
      }
    },
    {
      "id": "work-orders-table",
      "type": "table",
      "panelLayout": {
        "size": {
          "value": 80,
          "min": 35
        }
      },
      "request": {
        "metaTypeName": "WorkOrder"
      },
      "columns": [
        {
          "attribute": "itemId",
          "label": "Номер",
          "fixedWidth": "8rem"
        },
        {
          "attribute": "name",
          "label": "Наименование"
        }
      ]
    }
  ]
}

Verified demos ​

Open an ordered message-and-table group Open a vertically sized group

The current fixtures demonstrate composition and child sizes. They do not prove that resizable disables resizing.

Exact parameter reference ​

Continue with common panel configuration, then choose Tabs or Condition if children should not all remain visible.