> newInstance(Class presentationType, Class modelType) {
return getCustomConverter(presentationType, modelType)
.or(() -> fallback.newInstance(presentationType, modelType));
}
private Optional> getCustomConverter(Class presentationType, Class modelType) {
// custom logic
return ...;
}
}
```
## Using JSR 303 Bean Validation
You can use `BeanValidationBinder` if you prefer to use Java Specification Requests (JSR) 303 Bean Validation annotations, such as `Max`, `Min`, and `Size`.
`BeanValidationBinder` extends `Binder` — and therefore has the same API — but its implementation automatically adds validators based on JSR 303 constraints.
To use Bean Validation annotations, you need a JSR 303 implementation, such as Hibernate Validator, available in your classpath. If your environment doesn’t provide the implementation (e.g., Java EE container), you can use the following dependency in Maven:
```xml
org.hibernate
hibernate-validator
5.4.1.Final
```
### Defining Constraints for Properties
To use JSR 303 Bean Validation annotations with `BeanValidationBinder`, for example, you would do something like this:
```java
public class Person {
@Max(2000)
private int yearOfBirth;
// Non-standard constraint provided by
// Hibernate Validator
@NotEmpty
private String name;
// + other fields, constructors, setters and getters
}
BeanValidationBinder binder =
new BeanValidationBinder<>(Person.class);
binder.bind(nameField, "name");
binder.forField(yearOfBirthField)
.withConverter(
new StringToIntegerConverter("Enter a number"))
.bind("yearOfBirth");
```
Constraints defined for properties in the bean work in the same way as if configured programmatically when the binding is created. For example, the following code snippets have the same result.
This first example is a declarative Bean Validation annotation:
```java
public class Person {
@Max(value = 2000, message =
"Year of Birth must be less than or equal to 2000")
private int yearOfBirth;
```
This next example is a programmatic validation using Binder specific API:
```java
binder.forField(yearOfBirthField)
.withValidator(
yearOfBirth -> yearOfBirth <= 2000,
"Year of Birth must be less than or equal to 2000")
.bind(Person::getYearOfBirth, Person::setYearOfBirth);
```
> **Note:** As an alternative to defining constraint annotations for specific properties, you can define constraints at the bean level. However, Vaadin’s `BeanValidationBinder` doesn’t currently support them. It ignores all JSR 303 validations that aren’t assigned directly to properties.
### Automatically Marking Form Fields as Required
Some built-in validators in the bean validation API suggest that a value is required in input field. The `BeanValidationBinder` automatically enables the visual "required" indicator using the `HasValue.setRequiredIndicatorVisible(true)` method for properties annotated with such validators.
By default, `@NotNull`, `@NotEmpty` and `@Size` (if `min()` value is greater than 0) configures the field as required. You can change this behavior using the `BeanValidationBinder.setRequiredConfigurator()` method.
As an example, the following shows how you might override the default `@Size` behavior:
```java
binder.setRequiredConfigurator(
RequiredFieldConfigurator.NOT_EMPTY
.chain(RequiredFieldConfigurator.NOT_NULL));
```
### Validation Groups (since V25.3)
A JSR 303 constraint can declare one or more *validation groups*. A group is a marker interface that allows a subset of the constraints of a bean to be validated, instead of all of them at once. This is useful when the same bean is edited in situations that have different requirements — for example, a draft that needs only a title, and a published article that also needs a summary and a body.
Constraints that don’t declare a group belong to the default group, which is represented by the `jakarta.validation.groups.Default` interface. `BeanValidationBinder` validates the constraints of the default group only, unless it’s configured to use other groups.
For example, the following bean declares constraints in the default group, in a `Draft` group, and in a `Publish` group:
```java
public interface Draft {
}
public interface Publish {
}
public class Article {
// Default group: always validated
@NotEmpty
private String title;
// Publish group only
@NotEmpty(groups = Publish.class)
private String summary;
// Draft and Publish groups, but not the default group
@Size(min = 10, groups = { Draft.class, Publish.class })
private String body;
// + constructors, setters and getters
}
```
#### Configuring the Groups to Validate
Pass the groups to the `BeanValidationBinder` constructor, or set them afterwards with the `setValidationGroups()` method. The configured groups apply to all validation the binder triggers, including the validation of a single field when its value changes:
```java
BeanValidationBinder binder =
new BeanValidationBinder<>(Article.class, Publish.class);
// Or, after the binder has been created:
binder.setValidationGroups(Publish.class);
```
Validation groups replace, rather than extend, the default group. In the example above, the `@NotEmpty` constraint on the `title` property is no longer validated, because it belongs to the default group. To validate the default group as well, list it explicitly:
```java
binder.setValidationGroups(Default.class, Publish.class);
```
Calling `setValidationGroups()` without arguments restores the default behavior of validating the default group only. The `getValidationGroups()` method returns the groups that are in effect, where an empty array means the default group.
A validation group has to be an interface, as required by the Jakarta Bean Validation specification. Passing anything else throws an `IllegalArgumentException`.
> **Note:** Changing the groups doesn’t update validation results that are already displayed. Call `validate()` after `setValidationGroups()` if the fields have already been validated against the previous groups.
#### Validating Other Groups on Demand
Some constraints are relevant only when the data is saved, and displaying their error messages while the user is still filling in the form is distracting. For these cases, the `validate()` and `isValid()` methods accept the validation groups to use for that single validation, leaving the configured groups untouched:
```java
publishButton.addClickListener(event -> {
if (binder.validate(Default.class, Publish.class).isOk()) {
articleService.publish(article);
}
});
```
Any validation triggered later — for example, by a field value change — uses the configured groups again.
`validate()` displays the validation results to the user by marking the invalid fields, whereas `isValid()` neither modifies the UI nor fires status change events, which makes it suitable for tasks such as enabling and disabling a save button. Passing an empty array of groups to either method validates against the configured groups.
#### Required Indicators
The required indicator that `BeanValidationBinder` sets automatically follows the configured validation groups. A field is marked as required only when a constraint that implies a required value — see [Automatically Marking Form Fields as Required](#automatically-marking-form-fields-as-required) — belongs to a group that’s validated. A field whose only such constraint declares a group that isn’t validated, for instance `@NotNull(groups = Save.class)` on a binder with no groups configured, doesn’t get a required indicator.
Reconfiguring the groups with `setValidationGroups()` updates the indicators of the fields that are already bound. An indicator that the application has changed itself after the field was bound is left alone, so that `setRequiredIndicatorVisible()` calls made by the application aren’t overridden.
The indicators follow the configured groups rather than the groups of a single `validate()` or `isValid()` call, so that they reflect what’s validated while the user is editing.
#### Group Inheritance & Sequences
A validation group can extend another group. Validating against the sub-interface also validates the constraints of the groups it inherits from:
```java
public interface FinalPublish extends Publish {
}
// Validates the constraints of both FinalPublish and Publish
binder.setValidationGroups(FinalPublish.class);
```
A group can also be declared as a `@GroupSequence` of other groups. The binder validates the constraints of the groups in the sequence, and takes them into account for the required indicators. The groups of a sequence are validated in the declared order, and validation stops at the first group that has violations:
```java
@GroupSequence({ Draft.class, Publish.class })
public interface FullPublish {
}
// Validates the constraints of the Draft group, and,
// if they pass, those of the Publish group
binder.setValidationGroups(FullPublish.class);
```
A `@GroupSequence` on a bean type redefines the default group of that type. The groups of such a sequence are therefore validated, and taken into account for the required indicators, whenever the default group is validated:
```java
@GroupSequence({ Draft.class, Draftable.class })
public class Draftable {
// Validated even though the binder has no groups configured
@NotEmpty(groups = Draft.class)
private String title;
}
```
#### Bean-Level Validators
`BeanValidationBinder` ignores JSR 303 constraints that aren’t assigned directly to properties, so class-level constraints have to be implemented as bean-level validators added with `withValidator()`. Such a validator can read the groups that are in effect from the binder, which allows it to validate the same groups as the field-level validation:
```java
binder.withValidator((article, context) -> {
BeanValidationBinder source =
(BeanValidationBinder) context.getBinder().orElseThrow();
Class[] groups = source.getValidationGroups();
// Run the class-level checks that apply to these groups
return ValidationResult.ok();
});
```
While a `validate()` or `isValid()` call that was given validation groups is running, `getValidationGroups()` returns the groups given to that method instead of the configured ones.
#### Validation Groups in BeanValidator
`BeanValidationBinder` adds a `BeanValidator` to each binding for you. When you add one to a plain `Binder` instead, pass the validation groups to its constructor:
```java
binder.forField(summaryField)
.withValidator(new BeanValidator(
Article.class, "summary", Publish.class))
.bind(Article::getSummary, Article::setSummary);
```
A `SerializableSupplier` of groups can be given in place of a fixed array. The supplier is queried on every validation, which allows the groups to change after the validator has been created:
```java
binder.forField(summaryField)
.withValidator(new BeanValidator(
Article.class, "summary", this::getCurrentGroups))
.bind(Article::getSummary, Article::setSummary);
```
The `BeanValidator.getValidationGroups()` method returns the groups the validator validates against, where an empty array means the default group.
`D8AE5573-0248-4DBC-A58E-CBEA8E8F0957`