IDO-Centric Development

IDO-Centric Development is an architectural approach in Mongoose that shifts business logic, data integrity rules, validation and property relationship definitions from forms and into the IDO (Intelligent Data Object) tier. Instead of encoding behavior in UI-layer constructs such as form scripting, enable-when expressions, event handlers, and component-level validators, this approach defines rules declaratively at the data layer, where they are enforced consistently regardless of how the data is accessed.

The Form-Centric Problem

How it worked before

Historically, Mongoose-based applications defined data integrity, validation, and property relationship rules within forms. Business logic, such as which fields are enabled, what values are valid, when fields should be cleared, and how properties relate to each other, was implemented using:
  • Enable-when or Required-when expressions on individual form components.
  • Data-change event handlers that trigger multiple behaviors including method calls and form scripting.
  • Form scripts containing procedural logic for validation, value manipulation, and conditional behavior.
  • Startup methods and global variables that load system settings (feature flags, parameters, permissions) at session login for use in form logic.
  • Custom Load Methods, and Load/Save Override methods that are defined in the collection of a form override the load or save logic of the toolset.
  • Component-level validators assigned directly to form components.
  • Component classes and property class extensions that define validators inherited by form components.

This approach place the form at the center of all business rules and validation enforcement.

The Problems

These are not theoretical concerns, they represent real inconsistencies and maintenance burdens observed across Mongoose applications.
  • Inconsistency across forms - when multiple forms maintain the same data each form must independently re-implement the same rules and assign the same validators. This leads to drift, one form enforces a rule correctly although another misses it or implements it differently.
  • Bypassed rules through direct IDO access - integrations, custom code, API consumers, and the Application Even System (AES) that interact with IDOs directly bypass all form-level rules and validators entirely. Data integrity rules and validation defined only in forms provide zero protection when data is modified outside the UI.
  • Complicated form development - implementing rules in forms requires wiring together multiple constructs: enable-when expression on every affected component, event handlers, scripts, validators on each component, and careful coordination across grid views and detail views. This complexity increases development time and introduces fragility.
  • Duplication and maintenance burden - the same logical rule or the same validation must be expressed redundantly, once per component, per view, per forms. Changes to the rule or validator require updates in every location.

A concrete example

Consider a Report Options form with these business rules:
  • Printer Name is enabled and required when the output format is a printer format.
  • Output Directory, Attach Report, and Auto View are enabled when the format is not a printer format.
  • Switching across the printer or non-printer boundary clears the no-longer-applicable values.
  • User and Task Name fields require special handling to allow blank values on save.
In the form-centric approach, implementing these rules required:
  • Multiple enable-when and required-when expressions (one per component, per view).
  • Data-change event handlers with associated form scripts.
  • Scripts called during save that loop through every row to apply special handling.
  • Validators assigned to individual form components.

All this logic is invisible to any non-form consumer of the same IDO.

The IDO-Centric Solution

Core Principle

The fundamental shift is define rules where the data live, not where the data is displayed.

The solution is to implement data-driven rules, validation, and behavior directly in IDOS. These are enforced during update collection processing and inherited into forms for interactive use. The IDO becomes the single source of truth for how data should behave, forms become a presentation layer that inherits that behavior automatically.

This ensures:
  • Consistency - the same set of rules and validation applies across all forms that maintain the same data, and across all direct use of the IDO.
  • Protection - integrations, the Application Event System (AES), and code access the IDO directly are subject to the same data integrity rules and validators.
  • Simplification - forms inherit rules and validators from the IDO rather than re-implementing them, dramatically reducing form complexity.
  • Single source of truth - A rule or validator is defined once in the IDO and takes effect everywhere.

Goals

  • Enforce data integrity at the IDO tier - rules and validation apply during update collection processing regardless of the caller (form, integration, AES, or code).
  • Inherit behavior into the UI - forms automatically pic up IDO-defined rules and validators and apply them dynamically during user interaction, without requiring form-level scripting, expressions, or component-level configuration.
  • Simplify form development - reduce or eliminate the need for enable-when expressions, required-when expressions, data-change event handlers, form scripts, and component-level validator assignments for common data integrity patterns.
  • Ensure cross-form consistency - all forms bound to the same IDO automatically share the same behavior without independent implementation.
  • Support declarative definition - rules and validators are defined as data (metadata) rather than procedural code, making them easier to understand, maintain, and transport across environments.