| Метод | Описание |
|---|---|
| disableDefaultConstraintViolation | Отменяет генерацию задаваемого по умолчанию объекта ConstraintViolation |
| getDefaultConstraintMessageTemplate | Возвращает актуальное сообщение, заданное по умолчанию, без интерполяции |
| buildConstraintViolationWithTemplate | Возвращает ConstraintViolationBuilder, обеспечивающий построение пользовательского отчета о нарушении ограничения |
Интерфейс ConstraintValidatorContext позволяет повторно определить заданное по умолчанию сообщение, связанное с ограничением. Метод buildConstraintViolationWithTemplate возвращает ConstraintViolationBuilder, опираясь на гибкий образец API, позволяющий создавать пользовательские отчеты о нарушениях. Следующий код добавляет к отчету информацию о новом нарушении ограничения:
context.buildConstraintViolationWithTemplate("Invalid protocol")
·······.addConstraintViolation();
Такая техника позволяет генерировать и создавать одно или несколько пользовательских сообщений-отчетов. Если рассмотреть пример с ограничением @URL из листинга 3.7, то мы увидим, что всему ограничению здесь соответствует лишь одно сообщение об ошибке (Malformed URL). Но у этого ограничения несколько атрибутов (protocol, host и port), и нам могут понадобиться специфичные сообщения для каждого из этих атрибутов, например: Invalid protocol (Недопустимый протокол) или Invalid host (Недопустимый хост).
Интерфейс ConstraintViolation описывает нарушение ограничения. Он предоставляет контекст, в котором произошло нарушение, а также сообщение, описывающее это нарушение. Подробнее об этом читайте в разделе «Валидация ограничений» данной главы.
В листинге 3.17 мы вновь рассмотрим класс реализации ограничения URL и воспользуемся ConstraintValidatorContext, чтобы изменить сообщение об ошибке. Код полностью отключает генерацию заданного по умолчанию сообщения об ошибке (disableDefaultConstraintViolation) и отдельно определяет сообщения об ошибках для каждого атрибута.
public class URLValidator implements ConstraintValidator<URL, String> {
··private String protocol;
··private String host;
··private int port;
··public void initialize(URL url) {
····this.protocol = url.protocol();
····this.host = url.host();
····this.port = url.port();
··}
··public boolean isValid(String value, ConstraintValidatorContext context) {
····if (value == null || value.length() == 0) {
······return true;
····}
····java.net.URL url;
····try {
······url = new java.net.URL(value);
····} catch (MalformedURLException e) {
······return false;
····}
····if (protocol!= null && protocol.length() > 0 && 
!url.getProtocol(). equals(protocol)) {
······context.disableDefaultConstraintViolation();
······context.buildConstraintViolationWithTemplate("Неверный
протокол"). addConstraintViolation();
······return false;
····}
····if (host!= null && host.length() > 0 &&!url.getHost(). startsWith(host)) {
······context.disableDefaultConstraintViolation();
······context.buildConstraintViolationWithTemplate("Неверный
хост"). addConstraintViolation();
······return false;
····}
····if (port!= -1 && url.getPort()!= port) {
······context.disableDefaultConstraintViolation();
······context.buildConstraintViolationWithTemplate("Неверный
порт"). addConstraintViolation();
······return false;
····}
····return true;
··}
}
Группы
Когда компонент валидируется, в ходе проверки одновременно проверяются все его ограничения. Но что, если вам требуется частично валидировать компонент (проверить часть его ограничений) или управлять порядком валидации конкретных ограничений? Здесь нам пригодятся группы. Группы позволяют сформировать набор тех ограничений, которые будут проверяться в ходе валидации.
На уровне кода группа представляет собой обычный пустой интерфейс.
public interface Payment {}
На уровне бизнес-логики группа имеет определенное значение. Например, рабочая последовательность Payment (Платеж) подсказывает, что атрибуты, относящиеся к этой группе, будут валидироваться на этапе оплаты в рамках заказа товара. Чтобы применить эту группу с набором ограничений, нужно использовать атрибут groups и передать ему этот интерфейс: