Validation support for warnings (or in general more ErrorLevels)

[stefanuebe]

Using validators together with binders currently only allow validation / handling of errors. There are user scenarios, where entering a value should not lead to an invalid form, but at least should show a warning or allow the developer to react programmatically to such warnings. In a more general way, it could be extended to allow using all existing ErrorLevels as a ValidationResult (e. g. when an app shall differentiate between normal errors and critical ones).

Creating a ValidationResult with for instance ErrorLevel.WARNING is already possible, but the Binder / Validator API does neither support showing this warning with a respective style (looks like an error) nor does it allow to check, whether there have been warnings or not.

Therefore the requested enhancement is to extend the Validator/Binder API to allow a more generic way of using ErrorLevels, for instance by

• adding new convenience methods isWarning() etc. for ValidationResult
• adapting the methods hasErrors()/getValidationErrors() from BinderValidationStatus to new methods hasResults(ErrorLevel) / getValidationResults(ErrorLevel); plus convenience methods hasWarnings/getValidationWarnings(), etc.
• Binder#validate should not only "react" to errors, but all types of ErrorLevels, fire a respective StatusChangeEvent and return a BinderValidationStatus containing all occurred ErrorLevels (e.g. warning and error).
• StatusChangeEvent also should provide the validation ErrorLevels , not only a boolean "hasValidationError".
• Validation result messages of other ErrorLevels should be shown as they are for errors, but with a different styling (with a Lumo default style, e.g. something yellow-ish for warnings, blue for info, etc.; which can be customized)
• adding Icons indicating the ErrorLevel (exclamation mark for warning, x in a circle for error, i in a circle for info)
• Not sure if needed, but maybe necessary for backward compatibility: Binder can be configured on which ErrorLevel (plus above) a status change event shall be fired (default is all, but then it can easily be set to ERROR)
• The handling of ValidationResults, which are "ok" (ErrorLevel null), should not change

General example use cases:

• a picked date lies in the past
• an entered password only contains lower case characters
• an uploaded image is too small to provide good quality

[knoobie]

We had this requirement as well, instead of failing the whole process the customer wanted to show that those fields "aren't filled optimal" like e.g.

• INFO (blue), WARN (yellow), ERROR (red) with different color codings to show that the given value is technically valid but can still be problematic later on
• Example: Age > 100 - could be a typo or correct. Only the user can know this. Show WARN "Given age is greater than 100. Are you sure this person is still alive?"

[javier-godoy]

I created a small POC in #10683 (just the part of propagating error levels through the theme attribute so that they can be styled as warnings or info messages; no changes to the Java API)

[pleku]

We find the the API proposed in the PR is problematic https://github.com/vaadin/flow/pull/10683#discussion_r625601266 but it should not be a big task to refactor it to something more versatile like suggested.