You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The default theme was changed (a while back) to no longer render validation messages in the validation error box at the top of the page and only report errors next to the field a validation message was linked to.
Unfortunately, the side effect of this change is validation messages not linked to a field (where it can be rendered) are no longer rendered and do not appear silently. The project still gets a "validation" error as it is included in the list of validation messages but the message is not rendered.
Technically, validation messages should always be linked to a component as they should convey an input error. Any other error messages (such as application state) which are not related to user input should be reported as an "error" in the error message box and not as a validation error.
So what can we do to prevent validation errors being created that are not linked to a component?
No longer allow "null" components to be used on diagnostic messages. This means projects that are creating these type of messages will start getting runtime errors (which is better than these messages not appearing silently)
Projects will need to change Application State messages from the validation lifecycle to after the validation lifecycle and then check application state and add an "error" message.
If the validation message is related to user input, it should be linked to the input field.
If the validation message relates to a group of fields or something like a WTable with no rows, then a WFieldErrorIndicator should be added to the page and used with the validation message.
Or...
Another consideration is allowing validation messages to be flagged as "error" state and have the message reported in the error message box. This could fall back to the existing API that if the message is not linked to a field assume it should be rendered in the error box.
The text was updated successfully, but these errors were encountered:
jonathanaustin
changed the title
Validation messages not linked to a component are not being rendered silently
Validation messages not linked to a component are not being rendered
Aug 26, 2020
The default theme was changed (a while back) to no longer render validation messages in the validation error box at the top of the page and only report errors next to the field a validation message was linked to.
Unfortunately, the side effect of this change is validation messages not linked to a field (where it can be rendered) are no longer rendered and do not appear silently. The project still gets a "validation" error as it is included in the list of validation messages but the message is not rendered.
Technically, validation messages should always be linked to a component as they should convey an input error. Any other error messages (such as application state) which are not related to user input should be reported as an "error" in the error message box and not as a validation error.
So what can we do to prevent validation errors being created that are not linked to a component?
No longer allow "null" components to be used on diagnostic messages. This means projects that are creating these type of messages will start getting runtime errors (which is better than these messages not appearing silently)
Projects will need to change Application State messages from the validation lifecycle to after the validation lifecycle and then check application state and add an "error" message.
If the validation message is related to user input, it should be linked to the input field.
If the validation message relates to a group of fields or something like a WTable with no rows, then a WFieldErrorIndicator should be added to the page and used with the validation message.
Or...
Another consideration is allowing validation messages to be flagged as "error" state and have the message reported in the error message box. This could fall back to the existing API that if the message is not linked to a field assume it should be rendered in the error box.
The text was updated successfully, but these errors were encountered: