Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Scout/Proposals/InputValidation
There have been several issues about the current concepts and implementation of the scout input validation. This page describes the status quo, problems and possible solutions.
Comments
- Validation is done on focus lost or on any key input (getConfiguredValidateOnAnyKey())
- Content set programmatically needs to be validated differently than user input (security restrictions), currently one validate method in the client model
Current Usage
parse
protected String parseValueInternal(String text) throws ProcessingException protected T execParseValue(String text) throws ProcessingException
- Conversion: convert String to typed value (convert to number, String to uppercase/lowercase, trim)
- Throw Exception on parse Error (error status)
validate
protected String validateValueInternal(String rawValue) throws ProcessingException protected String execValidateValue(String rawValue) throws ProcessingException
- Change value (only accept single value in list boxes, number range, getConfiguredTreat0AsNull, to uppercase/lowercase
- Validation on the field itself: throw exception on invalid value (length check)
- React on event and do something (focus lost or with getConfiguredValidateOnAnyKey=true on key event (e.g. traverse focus, ...)
format
protected String formatValueInternal(T validValue) protected String execFormatValue(T validValue)
- Convert the value to a string (display text)
changed
protected void execChangedValue() throws ProcessingException
- React on change event and set other fields (call services, update field color, etc.)
- Validation using multiple fields
Documentation & Discussions
Wiki
Forum
[1] Summary of problems
- IFormField.getValue() always returns the last valid value and not the displayed value. IFormField.getErrorStatus returns an error, if there is one, but error value
-> Depending on your use case you might need to check the error status before reading the value -> execChangedValue not firing if an invalid value is reverted back to the previous value
- Invalid value set programmatically
-> Because the framework worka with the assumption that only valid values are set in the scout model layer, the framework is acting wired when a wrong value is set. The invalid value is not shown in the GUI, only the error. ErrorStatus and displaytext are inconsistent
- API
- SmartField.execvalidatevalue cannot be used - Update the value of a field during its own execChangedValue() event. - Controlling if execChangedValue() is called or not.
[2] Disable OK Button on error
If there is at least one field having errorStatus with severity equals to ERROR, then the Button OK will be disabled. -> The "Scout way" is to leave the OK button enabled all the time and rather present a error message to the user when he clicks it.
[3] Limiting input in FormFields, e.g.
- suppression of non-numeric input in number fields
- suppression of digits in string fields
- limiting the number of characters that can be entered in a field
[4] SmartField.execvalidatevalue cannot be used
SmartField.execvalidatevalue is final
[5] Not possible to mix execValidateValue and execChangedValue
Bugzilla
UI
- bug 419693 Field not set after validation failure
- bug 440134 AbstractDateField#validateValueInternal - Add NPE guard
- bug 417695 AbstractDateField truncates dates with time by using getDateFormat in validateValueInternal
Server
- bug 420524 ValidationCheck fails for formfields in template boxes with master required = true
- bug 384042 ValidationRule.MASTER_VALUE_FIELD not working
- bug 370123 Annotation @MaxLength in property of a form does not change the validation length