Skip to main content
Jump to: navigation, search


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.


  • 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


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)


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, ...)


protected String formatValueInternal(T validValue)
protected String execFormatValue(T validValue) 
  • Convert the value to a string (display text)


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




[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



  • 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


  • 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

Back to the top