-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: explain constraint validation, add error messages #3640
base: latest
Are you sure you want to change the base?
Conversation
@@ -193,10 +193,16 @@ The pattern is a regular expression used to validate the full value entered into | |||
[%collapsible] | |||
==== | |||
A separate single-character, regular expression can be used to restrict the characters that can be entered into the field. Characters that don't match the expression are rejected. | |||
|
|||
However, programmatically set values are not subject to this restriction, even if they contain disallowed characters. To validate these values, a pattern constraint should be used additionally. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to add this note but I've realized there is a complication. ComboBox and MultiSelectComboBox both have setAllowedCharPattern
, but they don't have setPattern
or if they do, it doesn't work, see vaadin/flow-components#6635.
I'm now not sure. I wonder whether there is actually a use-case for setAllowedCharPattern
for MultiSelectComboBox. At first glance, the required
constraint seems to be the only reasonable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess you could have a CB where you should only be able to enter numbers or something. In any case, both pattern and allowChars are really only meaningful for custom entry. I'd mention it as planned for now and see if we can fix 6635.
@@ -144,7 +144,7 @@ Disabled fields can be useful in situations where they can become enabled based | |||
|
|||
|
|||
//// | |||
CONSTRAINT FEATURES | |||
VALIDATION FEATURES | |||
//// | |||
|
|||
// tag::constraints-intro[] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't comment an unchanged line, but shouldn't the heading below also say Validation?
@@ -193,10 +193,16 @@ The pattern is a regular expression used to validate the full value entered into | |||
[%collapsible] | |||
==== | |||
A separate single-character, regular expression can be used to restrict the characters that can be entered into the field. Characters that don't match the expression are rejected. | |||
|
|||
However, programmatically set values are not subject to this restriction, even if they contain disallowed characters. To validate these values, a pattern constraint should be used additionally. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess you could have a CB where you should only be able to enter numbers or something. In any case, both pattern and allowChars are really only meaningful for custom entry. I'd mention it as planned for now and see if we can fix 6635.
Co-authored-by: Rolf Smeds <[email protected]>
Co-authored-by: Rolf Smeds <[email protected]>
Co-authored-by: Rolf Smeds <[email protected]>
Co-authored-by: Rolf Smeds <[email protected]>
Co-authored-by: Rolf Smeds <[email protected]>
Co-authored-by: Rolf Smeds <[email protected]>
Explains constraint validation and updates the examples to use new i18n error messages for:
Part of #3548