Load collections with requests

Requests connect a panel to object data. Choose the strategy from the data relationship, not from the visual panel: a Table may load a MetaType collection, linked objects, a method result, or a custom HTTP response, while a dependent detail surface may load one event-selected object.

This guide covers the shared runtime request router. A variant can expose a narrower local type or add its own request behavior, so confirm the variant guide before copying a request into another panel.

Decide which strategy to use

User problem	Required discriminator	Runtime strategy	Query ownership
List objects of one MetaType	metaTypeName	standard object search	server
List objects reached through a link	getSelectedObjectForEventId + linkName, without metaTypeName	linked objects	server
List objects whose attribute points to the selection	metaTypeName + event ID + linkedAttribute	linked-attribute search	server
Load one known or selected object	an ObjectSelector supplied by the consumer	single object	server
Run a MetaMethod as the data source	methodName	method	method response
Adapt arbitrary JSON rows	customRequest	custom HTTP	client pagination and sorting

All selected-object strategies require a prior panel event that stores an object selector with addSelectedObjectToRequest.

Strategy precedence

When several discriminator fields appear together, the shared router chooses the first matching strategy:

1. customRequest
2. methodName
3. consumer-supplied single objectSelector
4. metaTypeName + selected event + linkedAttribute
5. selected event + linkName without metaTypeName
6. metaTypeName

This precedence is a compatibility rule, not a configuration technique. Keep one clear discriminator set per request. A customRequest silently wins over an accidentally retained metaTypeName, and a method request wins over both linked and standard fields.

Projection and attribute paths

For standard and linked requests, the object projection is chosen in this order:

1. an explicit projection supplied by the calling consumer;
2. request.attributeList;
3. the panel's direct column attributes.

The router deduplicates paths and converts nested dots to the API pipe format. For linked-object requests, link.quantity becomes link:quantity; link attributes are excluded from a standard object projection. Filters, sorts, and editor fields do not automatically enlarge a Table projection.

Custom requests do not use the object projection. Their returned row keys are adapted to attributes and optional column dataType metadata.

Standard request

Use a standard request for an independently queryable MetaType.

{
  "request": {
    "metaTypeName": "ProductionOrder",
    "attributeList": ["code", "status", "product.name"],
    "findAttributes": [
      {
        "attribute": { "name": "status", "value": "released" },
        "compare": "EQUAL"
      }
    ],
    "sortParams": [
      { "attribute": "code", "sortDirection": "ASC" }
    ]
  },
  "pagination": {
    "rowsPerPage": [10, 25, 50]
  }
}

The first rowsPerPage value is the initial page limit. The response pagination becomes the rendered total, limit, and offset.

Linked requests

Link entity

Use linkName when the backend relationship itself defines the collection. The selected parent comes from the event.

{
  "request": {
    "getSelectedObjectForEventId": "order-selected",
    "linkName": "OrderOperation",
    "reverse": false,
    "attributeList": ["code", "status", "link.sequence"]
  }
}

reverse is false unless explicitly true. Filters and sorts for obj and link fields receive endpoint-specific prefixes during transport serialization.

Linked attribute

Use linkedAttribute when the child MetaType stores a reference attribute instead of being loaded through getLinkedObjects.

{
  "request": {
    "metaTypeName": "Operation",
    "getSelectedObjectForEventId": "order-selected",
    "linkedAttribute": "order"
  }
}

The runtime appends an equality filter for linkedAttribute and the selected object GUID. Your configured findAttributes remain in the request.

Method request

A method source uses the same object-endpoint model as runMethod actions.

{
  "id": "local-shared-config-method-request",
  "type": "table",
  "request": {
    "methodName": "FindLocalOrdersForAnchor",
    "parent": "LocalOrder",
    "objects": [
      {
        "objectId": {
          "objectGuid": "local-order-001"
        }
      }
    ]
  },
  "columns": [
    { "attribute": "code", "label": "Code" },
    { "attribute": "product", "label": "Product" },
    { "attribute": "status", "label": "Status" },
    { "attribute": "priority", "label": "Priority" }
  ]
}

The method response is treated as an object collection. Current Table runtime supports this route through the shared router even though older Table-local request declarations and prose omit it. The shared endpoint resolver turns the configured objectId into the GUID sent in objects; the runtime then posts parent, methodName, that GUID array, and an empty params object to /MetaMethods/Run. Filters, sorting, and pagination are not applied by the method executor itself; the method contract must return the usable result.

The checked-in local handler recognizes this fixture-only method and requires the matching LocalOrder parent plus the local-order-001 anchor. It returns the shared three-row local-order dataset in ObjectsResponse shape. This is proof of the real frontend execution path, not a production method-name claim.

Open the Method request tab and load Table rows through MetaMethods/Run

Custom HTTP request

Use a custom request only when the endpoint returns rows that are not available through the standard object APIs.

{
  "request": {
    "customRequest": {
      "method": "GET",
      "url": "/reports/order-progress",
      "idField": "orderId",
      "dataPath": "data.rows"
    }
  },
  "pagination": {
    "rowsPerPage": [10, 25]
  },
  "columns": [
    { "attribute": "orderId", "label": "Order", "dataType": "Guid" },
    { "attribute": "progress", "label": "Progress", "dataType": "Double" }
  ]
}

The current executor fetches the configured URL and method, extracts the array at dataPath when provided, then sorts and paginates the raw array in the client. idField defaults to id; the transformer converts that field to the row's id, objectGuid, and objectSelector.objectGuid. The field must therefore be present and unique across the complete response when row identity matters. A matching column dataType takes precedence; otherwise the runtime infers a type from the returned value.

The checked-in shared-config fixture exercises a concrete custom response:

{
  "id": "local-shared-config-custom-request",
  "type": "table",
  "request": {
    "customRequest": {
      "method": "GET",
      "url": "/applications/local-panel-fixtures/json-data",
      "dataPath": "panel.panels",
      "idField": "type"
    }
  },
  "pagination": { "rowsPerPage": [1, 2] },
  "columns": [
    {
      "attribute": "id",
      "dataType": "String",
      "label": "Panel ID",
      "sortable": true
    },
    {
      "attribute": "type",
      "dataType": "String",
      "label": "Type",
      "sortable": true
    },
    {
      "attribute": "panelLayout",
      "dataType": "Json",
      "label": "Size settings"
    }
  ]
}

The local endpoint returns the base fixture application's JSON envelope. panel.panels is a real two-row array, and its message and table values make type a non-default unique row identifier for this fixture. Page sizes 1 and 2 and the sortable id/type columns exercise the client-side controls. The current custom executor sends only the configured URL and method; do not add request body or header examples to this journey.

Open the Custom request tab with nested extraction, typed rows, sorting, and client pagination

Filters

findAttributes is the server request filter. Each entry selects one namespace: attribute, obj, or link, and one comparison.

Comparison	Value rule
EQUAL, NOT_EQUAL, CONTAIN, START_WITH	Provide name and value.
EMPTY, NOT_EMPTY	The comparison does not require a meaningful value.

{
  "findAttributes": [
    {
      "attribute": { "name": "code", "value": "PO-" },
      "compare": "START_WITH"
    },
    {
      "link": { "name": "relationKind", "value": "primary" },
      "compare": "EQUAL"
    }
  ]
}

Nested attribute paths use dots in panel JSON and are serialized to pipes for the API. Linked-object filters add obj: or link: only where the endpoint requires them.

A Table's filter.fields configures the visible filter UI; the submitted values become runtime findAttributes. The declared request.filter[] field is not the active filter path.

Sorting

Each sortParams entry selects attribute, obj, or link and a direction. Persisted ascending is "ASC"; descending is the legacy value "Desc". The transport normalizes them to API "Asc" and "Desc".

{
  "sortParams": [
    { "attribute": "priority", "sortDirection": "Desc" },
    { "attribute": "code", "sortDirection": "ASC" }
  ]
}

Standard and linked strategies send sorting to the server. Custom rows are sorted and paginated in the client. A sortable column only exposes the user interaction; it does not add the attribute to an explicitly configured request.attributeList.

Pagination behavior

• The first pagination.rowsPerPage entry is the initial Table limit.
• Changing page or page size updates { limit, offset }.
• Applying a new visible filter resets offset to 0 and preserves the limit.
• Standard, linked, and linked-attribute requests send pagination to the API.
• Custom requests slice the complete returned array locally.
• A missing Table pagination config falls back to the renderer's default options. Do not infer that default for other variants.

Minimal valid configuration

{
  "id": "orders",
  "type": "table",
  "request": { "metaTypeName": "ProductionOrder" },
  "columns": [{ "attribute": "name", "label": "Order" }]
}

Complete master-detail example

The following child request cannot run alone: the parent event is its required input.

{
  "id": "master-detail",
  "type": "group",
  "groupLayout": { "type": "rows" },
  "panels": [
    {
      "id": "orders",
      "type": "table",
      "request": { "metaTypeName": "ProductionOrder" },
      "events": [
        {
          "id": "order-selected",
          "name": "onObjectSelect",
          "actions": [{ "name": "addSelectedObjectToRequest" }]
        }
      ],
      "columns": [{ "attribute": "code", "label": "Order" }]
    },
    {
      "id": "operations",
      "type": "table",
      "condition": {
        "scenario": "objectSelected",
        "eventId": "order-selected"
      },
      "request": {
        "metaTypeName": "Operation",
        "getSelectedObjectForEventId": "order-selected",
        "linkedAttribute": "order"
      },
      "filter": {
        "fields": [{ "attribute": "status", "label": "Status" }]
      },
      "pagination": { "rowsPerPage": [10, 25] },
      "columns": [
        { "attribute": "code", "label": "Operation", "sortable": true },
        { "attribute": "status", "label": "Status" }
      ]
    }
  ]
}

Open a linked-attribute request with selection and visible filtering Open standard, linked, and single-object request paths

Limits and current drift

• Request fields are not runtime schema-validated before strategy selection.
• A selected-event request waits on live event state; the event declaration alone does not supply an object.
• Method requests are implemented by the shared router but incompletely represented in older Table-local types and source documentation.
• The checked-in method fixture proves the Table transport and response path against the local fixture API. Its method name and dataset remain fixture-specific; production method availability still belongs to the backend contract.
• request.filter[] is declared in older Table configuration but is not the active filtering model.

Exact property reference

Projection and standard requests:

• request.metaTypeName
• request.attributeList[]

Linked requests:

• request.getSelectedObjectForEventId
• request.linkName
• request.reverse
• request.linkedAttribute

Method requests:

• request.methodName
• request.parent
• request.objects[]

Custom HTTP requests:

• request.customRequest.method
• request.customRequest.url
• request.customRequest.idField
• request.customRequest.dataPath

Filters:

• request.filter[]
• request.findAttributes[]
• request.findAttributes[].attribute.name
• request.findAttributes[].attribute.value
• request.findAttributes[].obj.name
• request.findAttributes[].obj.value
• request.findAttributes[].link.name
• request.findAttributes[].link.value
• request.findAttributes[].compare

Sorting:

• request.sortParams[]
• request.sortParams[].attribute
• request.sortParams[].obj
• request.sortParams[].link
• request.sortParams[].sortDirection

Table pagination:

• pagination.rowsPerPage[]

Next tasks

• Render and edit typed values
• Resolve selected objects in editors
• Connect the source panel event
• Follow the master-detail journey