Skip to main content

Page and Component reference

A Page is an HMI screen used by an operator. A Component is a reusable visual template within an App, mainly for repeated content such as Repeater items. Use a Page for a complete screen and a Component for a consistent repeated item.

When to use this page​

  • You need to choose between a Page, Component, Widget, or Page method.
  • A button, input, or table event does not trigger the expected action.
  • Dynamic text, Object state, Variable, or i18n binding is incorrect.
  • Repeater items affect one another or a Component input is incomplete.
  • Page or Widget visibility does not match the signed-in App user's roles.

Entry point and core objects​

Create or open a Page under Resources → Pages. Manage Components in the Components group under Pages. Select empty canvas space for Page properties, or select a Widget for its content, layout, style, action, and permission properties.

ObjectPurpose
PageA navigable runtime screen that can be selected as the home page
WidgetText, button, input, table, chart, image, video, 3D, upload, or another UI element
Page methodUI logic called by the Page lifecycle or a Widget event
ExpressionA {{ ... }} binding from a Widget property to current runtime data
ComponentAn App-level template that accepts props and renders the same structure repeatedly
requiredRolesApp roles that control Page access or Widget visibility

Page methods​

TypeBest for
Flow methodCalling an Object or Query, showing a message, applying a condition, and simple ordered actions
TypeScript methodComplex type conversion, combining return values, and UI logic that is clearer as code

Create a method in the Page Methods properties, then select it from a Widget event or action property. An action should be a structured method binding produced by the editor or AI. Do not paste arbitrary script text into an action field.

Keep Page methods short and focused on UI coordination. Put stable equipment capabilities in an Object and put sequences with waits, timeouts, and recovery in a Graph.

Expressions and runtime capabilities​

Common entry points are:

EntryUse in a Page
QX.objectsRead Object runtime state, or call Object and Graph-extended methods from a method
QX.variablesRead an App Variable
QX.queriesCall an App-level HTTP Query from a Page method
QX.widgetsAccess a saved Widget from the current Page method
QX.globalsKeep small shared values needed by the current Page interaction
QX.actionsNavigation and other runtime-page interactions
QX.i18nRead an App translation in the current runtime-page language

Examples:

{{ QX.variables.currentOrder }}
{{ QX.objects["station"].variables.runState }}
{{ QX.i18n.get("startButton") }}

Expressions are for immediate values. They are not a place for await, long polling, or equipment operations with side effects. Call an Object or Graph method to change Object state. Use Graph Variable nodes or an explicit backend capability to write an App or Saved Variable.

Components and Repeaters​

A Component is not a standalone Page and has no independent runtime entry point. It defines the visual structure of a repeated item:

  1. Declare props in the Component and use sampleProps to inspect its design state.
  2. Use self.props for the full input in Widget properties and methods. Repeater items may also use the current item and index.
  3. Select the Component in a Page Repeater and pass data for each item.
  4. Every runtime instance has isolated Widget and state context. Do not depend on internal Widgets from another instance.

Common Components include station cards, alarm rows, I/O status rows, and task badges.

Permissions​

  • Page requiredRoles controls which App users may open the Page.
  • Widget requiredRoles controls whether a user with a matching role can see that Widget.
  • The editor shows every Page and Widget for authoring. Test permissions from a runtime page with real App users.
  • Role visibility is UI access control, not equipment Safety or server-side operation authorization.

Key rules​

  • Runtime Page and Component code belongs to the runtime surface and does not require the editor canvas to execute.
  • Page-local Queries are not supported. Maintain all Queries centrally in App Settings.
  • A Component is an independent App resource, not data embedded in one Page.
  • Page methods and expressions use QX for runtime capabilities and do not depend on editor-internal objects.
  • Do not put long equipment actions, polling, or process interlocks in a Page method.
  • When an external change reaches a tab with unsaved work, resolve the conflict before Save.

How to validate​

  1. Save the Page or Component and confirm that Problems has no Widget, method, or expression error.
  2. Use View mode to test real button, input, table, and 3D interaction.
  3. Test a Component with different sampleProps, then use several Repeater rows to confirm instance isolation.
  4. Confirm that the intended Page is the home page or is reachable by navigation.
  5. Start or Debug, then validate data refresh, actions, error messages, and language from a runtime page.
  6. Test Page and Widget visibility with an anonymous user, a normal role, and Admin.