Spring in Action Covers Spring 5-1--11 - страница 23
Чтобы проверить отправленное Taco, необходимо добавить аннотацию Java Bean Validation API’s @Valid
к аргументу Taco метода processDesign() у DesignTacoController.
Листинг 2.12 Проверка POST-запроса Taco
@PostMapping
public String processDesign(@Valid Taco design, Errors errors) {
if (errors.hasErrors()) {
return "design";
}
// Save the taco design...
// We'll do this in chapter 3
log.info("Processing design: " + design);
return "redirect:/orders/current";
}
@Valid аннотация говорит Spring MVC, чтобы выполнить проверку на представленном объекте Taco после того, как он привязан к представленным данным формы и перед вызовом метода processDesign(). Если есть какие-либо ошибки проверки, сведения об этих ошибках будут записаны в объект Errors, который передается в processDesign(). Первые несколько строк processDesign() проверяют объект Errors, через его метод hasErrors (), есть ли какие-либо ошибки проверки. Если есть, метод завершается без обработки Taco и возвращает имя представления "design" так, чтобы форма была перерисована.
Для выполнения проверки переданных объектов Order, аналогичные изменения также требуются в методе processOrder() в OrderController.
Листинг 2.13 Проверка -POST-запроса Order
@PostMapping
public String processOrder(@Valid Order order, Errors errors) {
if (errors.hasErrors()) {
return "orderForm";
}
log.info("Order submitted: " + order);
return "redirect:/";
}
В обоих случаях методу будет разрешено обрабатывать отправленные данные при отсутствии ошибок проверки. Если есть ошибки проверки, запрос будет перенаправлен в представление формы, чтобы дать пользователю возможность исправить свои ошибки.
Но как пользователь узнает, какие ошибки требуют исправления? Если вы не отобразите ошибки в форме, пользователю останется только гадать о том, как успешно отправить форму.
2.3.3 Отображение ошибок проверки
Thymeleaf предлагает удобный доступ к объекту Errors через свойство fields и с его атрибутом th:errors. Например, чтобы отобразить ошибки проверки в поле номер кредитной карты, можно добавить элемент , который использует эти ссылки на ошибки в шаблоне формы заказа следующим образом.
Листинг 2.14 Отображение ошибок проверки
th:if="${#fields.hasErrors('ccNumber')}" th:errors="*{ccNumber}">CC Num Error
Помимо атрибута класса, который можно использовать для стилизации ошибки, чтобы привлечь внимание пользователя, элемент использует атрибут th:if, чтобы решить, отображать ли . Метод hasErrors() свойства fields проверяет наличие ошибок в поле ccNumber. Если да, то будет отрисован.
Атрибут th: errors ссылается на поле ccNumber и, если для этого поля имеются ошибки, он заменит содержимое заполнителя элемента сообщением о результате проверки.
Если вы добавите похожие теги для других полей, вы увидите форму, которая выглядит как на рисунке 2.4, когда вы предоставляете недопустимую информацию. Ошибки указывают, что поля name, city и ZIP code оставлены пустыми и что все поля платежа не соответствуют критериям проверки.
Рисунок 2.4 Отображение ошибок проверки в форме заказа
Теперь контроллеры Taco Cloud не только отображают и записывают входные данные, но и проверяют соответствие информации некоторым основным правилам проверки. Давайте вернемся назад и пересмотрим HomeController из главы 1, глядя на альтернативную реализацию.
2.4 Работа с контроллерами отображения
До сих пор вы написали три контроллера для приложения Taco Cloud. Хотя каждый контроллер служит определенной цели в функциональности приложения, все они в значительной степени следуют одной модели программирования:
Они все аннотированы @Controller, чтобы указать, что они классы контроллеры, которые должны автоматически обнаруживаться при сканировании компонентов Spring и создаваться как bean в контексте приложения Spring.
Все, кроме HomeController, аннотируются @RequestMapping на уровне класса, чтобы определить базовый шаблон запроса, который будет обрабатывать контроллер.