anchor.diff:  }
   ----
   
  -It can sometimes be necessary to restrict when certain constraint annotations are active.
  -One such case is if administrator users are allowed to bypass some restrictions or if the backend should also perform validation, but with less strict constraints.
  -
  -
  -We can define a marker class for configuring a constraint to belong to a specific group and then configure [classname]#BeanBinder# to only use constraints from specific groups.
  -
  -[source, java]
  -----
  -// Constraint defined for the default group
  -@Size(min = 3, groups = FrontendValidation.class)
  -private String title;
  -
  -// Constraint defined for a specific group
  -@NotEmpty
  -private String name;
  -----
  -
  -We can now set our binder to use the frontend validation group in addition to the default group, leaving the backend to only validate based on the constraints defined for the default group.
  -
  -[source, java]
  -----
  -binder.setConstraintGroups(
  -  FrontendValidation.class,
  -  javax.validation.groups.Default.class);
  -----
  -
  -[TIP]
  -We can also configure our binder to not use the default group but only use a group that is not used for any of the constraint annotations on the bean.
  -By doing so, all annotations on the bean will be ignored so that we can define our own validation for the user interface even though Bean Validation is used by the application's backend.
  -
   Constraint annotations can also be defined on the bean level instead of being defined for any specific property.
  -Validation errors caused by that kind of validation might not be directly associated with any field component shown in the user interface, so [classname]#BeanBinder# cannot know where such messages should be displayed.
  +
  +[NOTE]
  +Bean level validation can only be performed once the bean has been updated. This means that this functionality can only be used together with `setBean`. You need to trigger validation manually if using `readBean` and `writeBean`.
  +
  +Validation errors caused by that bean level validation might not be directly associated with any field component shown in the user interface, so [classname]#BeanBinder# cannot know where such messages should be displayed.
   
   Similarly to how the [methodname]#withStatusLabel# method can be used for defining where messages for a specific binding should be showed, we can also define a [classname]#Label# that is used for showing status messages that are not related to any specific field.
   
  
positive.code: 
  binder.forField(titleField)
    // Shorthand for requiring the field to be non-empty
    .setRequired("Every employee must have a title")
    .bind(Person::getTitle, Person::setTitle);
  ----
  
  
negative.code: DateField returning = new DateField("Returning");
  
  // Store return date binding so we can revalidate it later
  Binding<Trip, LocalDate> returnBinding = binder.forField(returning)
    .withValidator(returnDate -> !returnDate.isBefore(departing.getValue()),
    "Cannot return before departing");
  returnBinding.bind(Trip::getReturnDate, Trip::setReturnDate);
  