The ValidationTest screen needs to trigger validation for the entire form inside the ValidationForm block when the user clicks the Save button.

The current approach uses a boolean flag called IsValidate within the form data. The block detects changes to this flag through OnParametersChanged and then triggers validation.

Components

Structure: ValidationValues

• Contains the data for 7 fields.
• Includes an additional attribute: IsValidate.

ValidationTest screen

• Declares a variable Form of type ValidationValues and passes it to the block through the Form input parameter.
• OnInitialize sets Form.IsValidate = False.
• SaveOnClick sets Form.IsValidate = True.
• ValidationFormOnChange receives data from the block's OnChange event and updates Form.

ValidationForm block

• OnParamsChanged is connected to OnParametersChanged and checks the value of Form.IsValidate.
• ValidateAll sequentially calls 7 OnBlur actions, one for each field.
• FieldOnChange triggers the OnChange event and passes the form data back to the screen. Each input calls this action through its OnChange event.

Execution Flow

1. OnInitialize sets Form.IsValidate = False.
2. The user clicks the Save button, triggering SaveOnClick, which sets Form.IsValidate = True.
3. Since Form is an input parameter of the ValidationForm block, this change triggers the block's OnParametersChanged event.
4. The block checks Form.IsValidate. If it is True, it executes ValidateAll, which sequentially calls the 7 validation actions:
   • SingleLineOnBlur
   • EmailOnBlur
   • MultiLineOnBlur
   • ReasonOnBlur
   • NumericOnBlur
   • IntegerOnBlur
   • FloatOnBlur
5. After ValidateAll completes, the block sets Form.IsValidate = False and then executes FieldOnChange. This action triggers the OnChange event and passes the updated Form back to the screen.
6. The screen receives the event through ValidationFormOnChange. If FormData <> Form, it assigns Form = FormData.
7. Meanwhile, SaveOnClick also calls the server action ValidateForm. If the form is invalid, the errors are stored in ServerErrors and displayed in the server error container.

Problems with the Current Approach

1. Control flags are mixed with business data.

IsValidate is a trigger signal, not actual form data, but it is stored in the same structure as the business data.

2. Poor scalability with multiple blocks.

When adding more blocks to the screen, each block requires its own flag and an additional assignment in SaveOnClick.

If a flag is forgotten, that block will not be validated, and there is no error or warning to indicate that validation was skipped.

Impact

• New blocks added to a screen can easily be missed during validation.
• The implementation is difficult to maintain and debug because the execution flow depends on changes to input parameters and indirect event triggering.

Alternative Approach Under Consideration

I am considering another approach:

When the user clicks the Save button, JavaScript would dispatch a custom event on the window object. All blocks on the screen would listen for this event and trigger their own validation logic when they receive it.

Are there any better or more efficient approaches you would recommend, apart from the two approaches described above?

Thank you for your suggestions!
Raid