5.3 Dynamic Behavior: Conditional Visibility & Editability

5.3 Dynamic Behavior: Conditional Visibility & Editability

Exam Focus: Dynamic behavior is among the most frequently tested concepts on the Intermediate Developer exam. You must master the differences between attribute-based and expression-based conditions, differentiate conditional editability rendering modes (Control vs. Text), evaluate event execution performance (client-side Nanoflows vs. server-side Microflows on On Change), understand the validation feedback lifecycle, and avoid confusing presentation-layer visibility with backend entity access security.

Static web forms fail to meet the usability standards expected of modern business software. Users expect responsive interfaces that adapt in real time—hiding irrelevant fields when an option is selected, locking inputs once an approval is recorded, and providing instant feedback when invalid values are entered. In Mendix, these capabilities are collectively governed by Conditional Visibility, Conditional Editability, and Widget Event Handlers.

---

Conditional Visibility: Attribute vs. Expression Engines

Every visual widget in Mendix Studio Pro supports conditional visibility. When enabled, the widget is only rendered if its configured condition evaluates to true at runtime.

+-----------------------------------------------------------------------------+
|                     Conditional Visibility Engine Options                   |
+-----------------------------------------------------------------------------+
| Based on Attribute   --> Fast, client-evaluated directly on single Boolean  |
|                          or Enumeration attribute values.                   |
| Based on Expression  --> Sophisticated logic combining multiple attributes, |
|                          system tokens, null checks, and associations.      |
+-----------------------------------------------------------------------------+

1. Based on Attribute

• Mechanics: The developer selects a single attribute of type Boolean or Enumeration from the enclosing data view object.
• Evaluation: For a Boolean attribute, the widget displays when the value is true (or false). For an Enumeration, the developer checks the specific enumeration values (e.g., Status = Submitted or Status = InReview) that trigger visibility.
• Efficiency: Evaluated instantaneously in the client browser runtime without invoking expression parsing overhead.

2. Based on Expression

• Mechanics: The developer constructs a boolean expression using the Mendix expression editor. Expressions can access:
  • The enclosing object attributes: $currentObject/TotalAmount > 5000
  • Associated entity attributes: $currentObject/Order_Customer/IsVIP = true
  • Current user and session context: $currentUser != empty
  • Built-in date and math functions: $currentObject/DueDate < [%CurrentDateTime%]
• Complex Compound Logic: Supports standard boolean operators (and, or, not):

  $currentObject/Status = MyModule.OrderStatus.Shipped 
  and ($currentObject/TrackingNumber = empty or $currentObject/ExpeditedShipping = true)
  

• Expression Limitations: An expression cannot perform arbitrary database retrieves or execute custom Java actions. All entities and associations evaluated in the expression must be available within the client object cache.

Conditional Editability & Read-Only Rendering Modes

While conditional visibility governs whether a widget appears on the screen, Conditional Editability dictates whether an end user can interact with and modify the widget's underlying value.

Editability Settings in Studio Pro

For any input control (e.g., text box, drop-down, check box, date picker), editability can be configured to:

1. Default: Inherits the editability state of the surrounding Data View or page layout.
2. Never (Read-Only): The field is permanently locked against user input.
3. Always (Editable): The field is permanently open for input, provided user security permits writing.
4. Conditional: The control becomes editable only when a specific attribute or boolean expression evaluates to true (e.g., $currentObject/Status = MyModule.OrderStatus.Draft).

Read-Only Style Modes: Control vs. Text

When an input widget becomes read-only, Studio Pro allows developers to select its visual presentation via the Read-only style property:

---

Critical Architecture Principle: UI Visibility is NOT Security

One of the most dangerous and common misconceptions among intermediate developers is relying on Conditional Visibility to secure sensitive application data.

[!IMPORTANT] Always apply the principle of defense in depth: Use Entity Access Rules to enforce strict data governance and regulatory authorization. Use Conditional Visibility exclusively to declutter the user interface and streamline business workflows.

---

Widget Event Triggers: On Change, On Enter, and On Leave

Interactive forms rely on event listeners attached to input widgets. Mendix provides three core event hooks:

1. On Change

• Execution: Fires immediately when the user changes the value of the control. For drop-downs and checkboxes, this triggers upon item selection; for text inputs, it triggers upon input blur or after typing stops (depending on debounce settings).
• Action Choices: Can execute a Microflow, execute a Nanoflow, Save changes, Cancel changes, Close page, or Call REST/Nanoflow action.
• Performance Strategy: Invoking a server-side Microflow on every input change initiates a network HTTP roundtrip. For high-frequency calculations (such as calculating LineTotal = Quantity * UnitPrice), configuring a client-side Nanoflow delivers instantaneous, zero-latency feedback without taxing the server.

2. On Enter (Focus)

• Execution: Fires when the user places cursor focus into the input widget (either by clicking or tabbing into the field).
• Typical Use Cases: Displaying contextual help instructions, loading dynamic dropdown suggestions, or highlighting the active form section.

3. On Leave (Blur)

• Execution: Fires when the user shifts focus away from the input widget.
• Typical Use Cases: Performing format verification (e.g., validating IBAN or Tax ID structures) or triggering auto-save microflows.

---

Form Validation Architecture & Validation Feedback Action

Mendix implements a dedicated modeling pattern for user input validation. Rather than raising unhandled exceptions or displaying generic pop-up error dialogs, microflows and nanoflows use the Validation Feedback activity.

Anatomy of Validation Feedback

1. Target Specification: The developer selects the specific entity object and the exact member attribute to receive feedback (e.g., Customer/EmailAddress).
2. Error Message: Provides a translatable error message template explaining the validation failure (e.g., "Please enter a valid corporate email address ending in @acme.com.").
3. Client-Side Rendering: Studio Pro renders the feedback as an accessible, high-contrast red error message anchored directly beneath the targeted input field.
4. Transaction Impact: The Validation Feedback action flags the active client form as invalid. If a microflow encounters validation feedback, the platform automatically halts default page close operations and prevents subsequent commit actions from saving corrupted data to the database.