Skip to main content

Entity - Processes

JDito processes can cause performance problems when they are:

  • Too slow due to inefficient logic
  • Executed too frequently, especially per record, which can accumulate significant processing time

Optimize Slow Processes​

Review JDito code for unnecessary or inefficient logic. Simplify wherever possible. Since JDito is JavaScript-based, general JS performance best practices apply. Refer to the "AID001 Coding Styles" document for clean, maintainable code structures.

Optimize Process Frequency​

Some JDito processes (like valueProcess or displayValueProcess) are executed per dataset. This adds up quickly when displaying lists or FilterViews. To reduce their impact:

Avoid valueProcess and displayValueProcess​

Use a SQL-based expression in the RecordFieldMapping instead. It is calculated once at load time, not per row, which significantly improves performance in list views like tables or treetables.

tip

For fields that appear only in detail views or edit dialogs — and not in large lists — using valueProcess may be acceptable and often simpler. In these cases, a SQL expression would only add unnecessary complexity.

Use conditional logic to skip execution where not needed​

For example:

if (vars.get("$sys.viewmode") != neon.FRAME_VIEWMODE_TABLE) {
  result.string(neon.COMPONENTSTATE_INVISIBLE);
}

Apply this technique to:

  • Actions that have no effect visible in the current View

  • EntityFields not included in a view (typically skipped automatically by ADITO; manual optimization is rarely necessary)

  • EntityField processes (e.g., iconProcess, titleProcess, tooltipProcess, stateProcess, onValidationProcess, onValueChange, dropDownProcess, mandatoryProcess)

  • Entity-related processes (e.g., iconIdProcess, imageProcess, colorProcess, contentTitleProcess, contentDescriptionProcess)

*Replace constant logic with parameters​

If a value is the same for all records, calculate it once in a Parameter’s valueProcess and read it from there in your entity.
The valueProcess of the Parameter is executed only once — when the Parameter is accessed for the first time. The result is cached and reused for all subsequent calls, avoiding redundant recalculations.

Split complex logic out of entity-level processes​

Move calculations to a separate hidden EntityField using a SQL expression, rather than embedding it in a frequently called process.

Skip unnecessary logic in edit mode​

Use this pattern:

const mode = vars.get("$sys.presentationmode");
const state = vars.get("$sys.operatingstate");

if (state == neon.OPERATINGSTATE_VIEW && mode == neon.CONTEXT_PRESENTATIONMODE_FULL) {
  // Run only in view mode
}

Remove unnecessary processes​

Review your project for any processes that are no longer needed or have no functional impact. This includes:

  • Processes that were once required but are now redundant due to changes in the application.
  • Processes that were added for testing or debugging purposes and are no longer relevant.

Limit execution of onValueChange execuion​

If using onValueChange, limit the types in onValueChangeTypes to only what's needed. Avoid enabling "Process" unless explicitly required.

address onValueChangeTypes Figure: Optimized onValueChangeTypes configuration

Additional Tips​

  • Avoid running dropDownProcess or mandatoryProcess in FilterViews.
  • Replace dropdown logic with SQL expression logic when possible.

Customizing Manual​

For further guidance, refer to the Customizing Manual.