Skip to main content

Execution Order of Entity Processes

tip

To learn more about the operating states, see: System state.

Order on load​

Figure: Execution order of processes when loading an Entity.

  1. onInit
    This process runs before the RecordContainer is loaded. It is typically used to initialize variables such as $global.variableName or $context.variableName.
  2. beforeOperatingState
    At this point, the Entity is already loaded, but no operating state has been entered yet. See System state.
  3. afterOperatingState
    At this stage, the operating state has been determined, but UI components are not loaded yet. This is the correct place to react to operating-state changes.
  4. afterUiInit
    This process runs after the UI has been initialized. You can use it for UI-related actions such as neon.addRecord.
  5. onValidation
    Use this process to validate field data before saving. It should be used only for validation and not for reacting to changes. If the onValidation process returns a text, ADITO automatically treats the validation as invalid, displays the message next to the Save button, and disables the button until the next validation run.
    Example: result.string("Your input must not include special characters like '&'.");
  6. onValueChange
    This EntityField process reacts to field changes. It can be used, for example, to update derived values or to enable or disable related UI elements depending on the input.
    • With property onValueChangeTypes, you can define which modifier types trigger the process, for example MASK or RECORD.
    • $local.modifiertype contains the modifier type that triggered the process. This is useful if different reactions are required for different trigger sources.

Order on save​

Saving an Entity with a dbRecordContainer​

Figure: Execution order of processes when saving an Entity with a dbRecordContainer.

Saving an Entity with a jditoRecordContainer​

Figure: Execution order of processes when saving an Entity with a jDitoRecordContainer.

afterSave-Process​

Descriptions of these processes can be found partly in their JSDoc and partly in the previous section about Load. The following additional notes are relevant:

  • afterSave
    The afterSave process exists to execute client-side commands after a record has been saved. Typical examples are showing a popup message or opening another Context. The same logic should not be implemented in onDBInsert or onInsert, because RecordContainer processes are not allowed to execute client commands such as neon.xxx or question.xxx. In addition, openContext does not behave reliably there.

    Please note the following:

    • afterSave runs exclusively on the client side. It must therefore not be used to trigger server-side changes, updates, or follow-up processes. If server-side actions are required, implement them in on(DB)Insert.
    • If afterSave opens a new Context, return result.string(true); to suppress the default post-save behavior.