검증 직접 처리 - 개발
@PostMapping("/add")
public String addItem(@ModelAttribute Item item, RedirectAttributes redirectAttributes, Model model) {
//검증 오류 결과를 보관하는 객체 생성
Map<String, String> errors = new HashMap<>();
//검증 로직
if(!StringUtils.hasText(item.getItemName())){
errors.put("itemName", "상품 이름은 필수 입니다.");
}
if(item.getPrice() == null || item.getPrice() < 1000 || item.getPrice() > 10000000){
errors.put("price", "가격은 1,000~ 1,000,000 까지 허용합니다. ");
}
if(item.getQuantity() == null || item.getQuantity() >= 9999){
errors.put("quantity", "수량은 최대 9,999 까지 허용합니다. ");
}
//특정 필드가 아닌 복합 룰 검증
if(item.getPrice() != null && item.getQuantity() !=null){
int resultPrice = item.getPrice() * item.getQuantity();
if(resultPrice <10000){
errors.put("globalError", "가격 * 수량의 합은 10,000원 이상이어야 합니다. 현재 값 ="+ resultPrice);
}
}
//검증에 실패하면 다시 입력 폼으로
if(!errors.isEmpty()){
log.info("errors = {}", errors);
model.addAttribute("errors", errors);
return "validation/v1/addForm";
}
//성공 로직
Item savedItem = itemRepository.save(item);
redirectAttributes.addAttribute("itemId", savedItem.getId());
redirectAttributes.addAttribute("status", true);
return "redirect:/validation/v1/items/{itemId}";
}
상품 등록 검증 HTML
글로벌 오류 메시지
<div th:if="${errors?.containsKey('globalError')}">
<p class="field-error" th:text="${errors['globalError']}">전체 오류 메시지</p>
</div>
• 타임리프의 th:if 를 사용하면 조건에 만족할 때만 해당 HTML 태그를 출력
만약 여기에서 errors가 null이라면 어떻게 될까?
생각해보면 등록폼에 진입한 시점에는 errors 가 없다.
따라서 errors.containsKey() 를 호출하는 순간 NullPointerException 이 발생한다.
errors?. 은 errors 가 null 일때 NullPointerException 이 발생하는 대신, null 을 반환하는 문법이다.
th:if 에서 null 은 실패로 처리되므로 오류 메시지가 출력되지 않는다.
필드 오류 처리
<input type="text" th:classappend="${errors?.containsKey('itemName')} ? 'fielderror' : _" class="form-control"
• classappend 를 사용해서 해당 필드에 오류가 있으면 field-error 라는 클래스 정보를 더해서 폼의 색깔을 빨간색으로
강조한다. 만약 값이 없으면 _ (No-Operation)을 사용해서 아무것도 하지 않는다
직접 처리 문제점
• item의 price, quantity 같은 숫자 필드는 타입이 Integer 이므로 문자 타입으로 설정하는 것이 불가능
• 숫자 타입에 문자가 들어오면 오류가 발생하나 이러한 오류는 스프링MVC에서 컨트롤러에 진입하기도 전에 예외가
발생 하기 때문에, 컨트롤러가 호출되지 않고, 400 예외가 발생
• item의 price에 문자를 입력하는 것처럼 타입 오류가 발생해도 고객이 입력한 문자를 화면에 남겨야 한다.
• 만약 컨트롤러가 호출된다고 가정해도 Item 의 price 는 Integer 이므로 문자를 보관할 수가 없다.
결국 문자는 바인딩이 불가능하므로 고객이 입력한 문자가 사라지게 되고, 고객은 본인이 어떤 내용을
입력해서 오류가 발생했는지 이해하기 어렵다.
BindingResult
필드 오류 - FieldError
if (!StringUtils.hasText(item.getItemName())) {
bindingResult.addError(new FieldError("item", "itemName", "상품 이름은 필수입니다."));
}
FieldError 생성자 요약
public FieldError(String objectName, String field, String defaultMessage) {}
필드에 오류가 있으면 FieldError 객체를 생성해서 bindingResult 에 담아두면 된다.
• objectName : @ModelAttribute 이름
• field : 오류가 발생한 필드 이름
• defaultMessage : 오류 기본 메시지
글로벌 오류 - ObjectError
bindingResult.addError(new ObjectError("item", "가격 * 수량의 합은 10,000원 이상이어야 합니다. 현재 값 = " + resultPrice));
ObjectError 생성자 요약
public ObjectError(String objectName, String defaultMessage) {}
특정 필드를 넘어서는 오류가 있으면 ObjectError 객체를 생성해서 bindingResult 에 담아두면 된다.
• objectName : @ModelAttribute 의 이름
• defaultMessage : 오류 기본 메시지
타임리프 스프링 검증 오류 통합 기능
타임리프는 스프링의 BindingResult 를 활용해서 편리하게 검증 오류를 표현하는 기능을 제공한다.
• #fields : #fields 로 BindingResult 가 제공하는 검증 오류에 접근할 수 있다.
• th:errors : 해당 필드에 오류가 있는 경우에 태그를 출력한다. th:if 의 편의 버전이다.
• th:errorclass : th:field 에서 지정한 필드에 오류가 있으면 class 정보를 추가한다.
글로벌 오류 처리
<div th:if="${#fields.hasGlobalErrors()}">
<p class="field-error" th:each="err : ${#fields.globalErrors()}" th:text="$
{err}">전체 오류 메시지</p>
</div>
필드 오류 처리
<input type="text" id="itemName" th:field="*{itemName}"
th:errorclass="field-error" class="form-control" placeholder="이름을
입력하세요">
<div class="field-error" th:errors="*{itemName}">
상품명 오류
</div>
BindingResult2
• 스프링이 제공하는 검증 오류를 보관하는 객체이다. 검증 오류가 발생하면 여기에 보관하면 된다.
• BindingResult 가 있으면 @ModelAttribute 에 데이터 바인딩 시 오류가 발생해도 컨트롤러가 호출된다!
예) @ModelAttribute에 바인딩 시 타입 오류가 발생하면?
• BindingResult 가 없으면 400 오류가 발생하면서 컨트롤러가 호출되지 않고, 오류 페이지로 이동한다.
• BindingResult 가 있으면 오류 정보( FieldError )를 BindingResult 에 담아서 컨트롤러를 정상 호출한다.
BindingResult에 검증 오류를 적용하는 3가지 방법
• @ModelAttribute 의 객체에 타입 오류 등으로 바인딩이 실패하는 경우 스프링이 FieldError 생성해서
BindingResult 에 넣어준다.
• 개발자가 직접 넣어준다.
• Validator 사용 이것은 뒤에서 설명
타입 오류 확인
숫자가 입력되어야 할 곳에 문자를 입력해서 타입을 다르게 해서 BindingResult 를 호출하고
bindingResult 의 값을 확인해보자.
주의
• BindingResult 는 검증할 대상 바로 다음에 와야한다. 순서가 중요하다. 예를 들어서 @ModelAttribute
• Item item , 바로 다음에 BindingResult 가 와야 한다.
BindingResult 는 Model에 자동으로 포함된다.
BindingResult와 Errors
• org.springframework.validation.Errors
• org.springframework.validation.BindingResult
BindingResult 는 인터페이스이고, Errors 인터페이스를 상속받고 있다.
실제 넘어오는 구현체는 BeanPropertyBindingResult 라는 것인데,
둘다 구현하고 있으므로 BindingResult 대신에 Errors 를 사용해도 된다.
Errors 인터페이스는 단순한 오류 저장과 조회기능을 제공한다.
BindingResult 는 여기에 더해서 추가적인 기능들을 제공한다.
addError() 도 BindingResult 가 제공하므로 여기서는 BindingResult 를 사용하자.
주로 관례상 BindingResult 를 많이 사용한다.
정리
BindingResult , FieldError , ObjectError 를 사용해서 오류 메시지를 처리하는 방법을 알아보았다.
그런데 오류가 발생하는 경우 고객이 입력한 내용이 모두 사라진다. 이 문제를 해결해보자.
FieldError, ObjectError
FieldError 생성자
public FieldError(String objectName, String field, String defaultMessage);
public FieldError(String objectName, String field, @Nullable Object rejectedValue, boolean bindingFailure, @Nullable String[] codes, @Nullable Object[] arguments, @Nullable String defaultMessage)
파라미터 목록
1. objectName : 오류가 발생한 객체 이름
2. field : 오류 필드
3. rejectedValue : 사용자가 입력한 값(거절된 값)
4. bindingFailure : 타입 오류 같은 바인딩 실패인지, 검증 실패인지 구분 값
5. codes : 메시지 코드
6. arguments : 메시지에서 사용하는 인자
7. defaultMessage : 기본 오류 메시지
ObjectError도 유사하게 두 가지 생성자를 제공
• 스프링이 BindingResult 매개변수에 field errors를 넣을 려고 할 때 price가 Integer가 아닌 "문자"가 넘어오는 경우 뭔가 올바르지 않음을 감지하고, new FieldError()를 만든다.
• 그러면 가격의 잘못된 문자인 qqq를 new FieldError() 메서드(생성자)의 세번째 파라미터인 rejectedValue에 담는다. 그 이후에 new FieldError객체를 BindingResult에 담은 후에 최종적으로 Controller를 호출한다.
오류 발생시 사용자 입력 값 유지
new FieldError("item", "price", item.getPrice(), false, null, null, "가격은 1,000 ~1,000,000 까지 허용합니다.")
• 사용자의 입력 데이터가 컨트롤러의 @ModelAttribute에 바인딩되는 시점에 오류가 발생하면 모델 객체의
사용자 입력값을 유지 하기 어렵다.
• 예를 들어서 가격에 숫자가 아닌 문자가 입력된다면 가격은 Integer타입이므로 문자를 보관할 수 있는 방법이 없다.
• 오류가 발생한 경우 사용자 입력 값을 보관하는 별도의 방법이 필요
• FieldError는 오류 발생시 사용자 입력 값을 저장하는 기능을 제공
타임리프의 사용자 입력 값 유지
th:field="*{price}" 타임리프의 th:field는 매우 똑똑하게 동작하는데, 정상 상황에는 모델 객체의 값을 사용하지만, 오류가 발생하면 FieldError에서 보관한 값을 사용해서 값을 출력
스프링의 바인딩 오류 처리
• 타입 오류로 바인딩에 실패하면 스프링은 FieldError를 생성하면서 사용자가 입력한 값을 보관
• 해당 오류를 BindingResult에 담아서 컨트롤러를 호출한다. 따라서 타입 오류 같은 바인딩 실패 시에도
사용 자의 오류 메시지를 정상 출력
오류 코드와 메시지 처리1
• FieldError , ObjectError 의 생성자는 codes , arguments 를 제공한다.
• 이것은 오류 발생시 오류코드로 메시지를 찾기 위해 사용된다.
errors 메시지 파일 생성
스프링 부트 메시지 설정추가
application.properties
spring.messages.basename=messages,errors
errors.properties
required.item.itemName=상품 이름은 필수입니다.
range.item.price=가격은 {0} ~ {1} 까지 허용합니다.
max.item.quantity=수량은 최대 {0} 까지 허용합니다.
totalPriceMin=가격 * 수량의 합은 {0}원 이상이어야 합니다. 현재 값 = {1}
참고 : errors_en.properties 파일을 생성하면 오류 메시지도 국제화 처리 가능
//range.item.price=가격은 {0} ~ {1} 까지 허용합니다.
new FieldError("item", "price", item.getPrice(), false, new String[]
{"range.item.price"}, new Object[]{1000, 1000000}
• codes : required.item.itemName를 사용해서 메시지 코드를 지정
• 메시지 코드는 하나가 아니라 배열로 여러 값을 전달할 수 있는데, 순서대로 매칭해서 처음 매칭되는 메시지가 사용됨
• arguments : Object[ ]{1000, 1000000} 을 사용해서 코드의 {0}, {1} 로 치환할 값을 전달한다.
오류 코드와 메시지 처리2
• 컨트롤러에서 BindingResult 는 검증해야 할 객체인 target(Item item) 바로 다음에 온다. 따라서
BindingResult 는 이미 본인이 검증해야 할 객체인 target(Item item) 을 알고 있다.
• BindingResult 가 제공하는 rejectValue() , reject() 를 사용하면 FieldError , ObjectError 를 직접 생성하지 않고, 깔끔하게 검증 오류를 다룰 수 있다.
rejectValue()
void rejectValue(@Nullable String field, String errorCode,
@Nullable Object[] errorArgs, @Nullable String defaultMessage);
reject()
void reject(@Nullable String field, String errorCode, @Nullable Object[] errorArgs, @Nullable String defaultMessage);
1. field : 오류 필드명
2. errorCode : 오류 코드(messageResolver를 위한 오류 코드)
3. errorArges : 오류 메시지에서 {0}을 치환하기 위한 값
4. defaultMessage : 오류 메시지를 찾을 수 없을 때 사용하는 기본 메시지
bindingResult.rejectValue("price", "range", new Object[]{1000, 1000000}, null)
• BindingResult는 어떤 객체를 대상으로 검증하는지 target을 이미 알고 있으므로 target에 대한 정도가 없어도 된다.
오류 코드와 메시지 처리3
#Level1
required.item.itemName: 상품 이름은 필수 입니다.
#Level2
required: 필수 값 입니다.
물론 이렇게 객체명과 필드명을 조합한 메시지가 있는지 우선 확인하고, 없으면 좀 더 범용적인 메시지를
선택하도록 추가 개발을 해야겠지만, 범용성 있게 잘 개발해두면, 메시지의 추가 만으로 매우 편리하게 오류
메시지를 관리할 수 있을 것이다.
• 스프링은 MessageCodesResolver 라는 것으로 이러한 기능을 지원한다
오류 코드와 메시지 처리4
MessageCodesResolver
• 검증 오류 코드로 메시지 코드들을 생성한다.
• MessageCodesResolver 인터페이스이고, DefaultMessageCodesResolver는 기본 구현체이다.
• 주로 다음과 함께 사용 ObjectError, FieldError
DefaultMessageCodesResolver의 기본 메시지 생성 규칙
객체 오류
객체 오류의 경우 다음 순서로 2가지 생성
1. code + "." + object name
2. code
예) 오류 코드: required, object name: item
1. required.item
2. required
필드 오류
필드 오류의 경우 다음 순서로 4가지 메시지 코드 생성
1.: code + "." + object name + "." + field
2.: code + "." + field
3.: code + "." + field type
4.: code
예) 오류 코드: typeMismatch, object name "user", field "age", field type: int
1. "typeMismatch.user.age"
2. "typeMismatch.age"
3. "typeMismatch.int"
4. "typeMismatch"
동작 방식
• rejectValue() , reject() 는 내부에서 MessageCodesResolver 를 사용한다. 여기에서 메시지코드들을 생성한다.
• FieldError , ObjectError 의 생성자를 보면, 오류 코드를 하나가 아니라 여러 오류 코드를 가질 수 있다.
MessageCodesResolver 를 통해서 생성된 순서대로 오류 코드를 보관한다.
FieldError→rejectValue("itemName", "required")
다음 4가지 오류 코드를 자동으로 생성
• required.item.itemName
• required.itemName
• required.java.lang.String
• required
ObjectError→reject("totalPriceMin")
다음 2가지 오류 코드를 자동으로 생성
• totalPriceMin.item
• totalPriceMin
오류 메시지 출력
타임리프 화면을 렌더링 할 때 th:errors가 실행된다. 만약 이때 오류가 있다면, 생성된 오류 메시지 코드를 순서대로 돌아가면서 메시지를 찾는다. 그리고 없으면 디폴트 메시지를 출력한다.
오류 코드와 메시지 처리5
핵심은 구체적인 것에서! 덜 구체적인 것으로!
MessageCodesResolver 는 required.item.itemName 처럼 구체적인 것을 먼저 만들어주고,
required 처럼 덜 구체적인 것을 가장 나중에 만든다.
이렇게 하면 앞서 말한 것 처럼 메시지와 관련된 공통 전략을 편리하게 도입할 수 있다.
정리
1. rejectValue() 호출
2. MessageCodesResolver 를 사용해서 검증 오류 코드로 메시지 코드들을 생성
3. new FieldError() 를 생성하면서 메시지 코드들을 보관
4. th:erros 에서 메시지 코드들로 메시지를 순서대로 메시지에서 찾고, 노출
오류 코드와 메시지 처리6
스프링이 직접 만든 오류 메시지 처리
• 검증 오류 코드는 다음과 같이 2가지로 나눌 수 있다.
1. 개발자가 직접 설정한 오류 코드→ rejectValue() 를 직접 호출
2. 스프링이 직접 검증 오류에 추가한 경우(주로 타입 정보가 맞지 않음)
• 스프링은 타입 오류가 발생하면 typeMismatch라는 오류 코드를 사용
• error.properties에 아래와 같은 내용을 추가하면 소스 코드를 수정하지 않고, 메시지 처리 가능
typeMismatch.java.lang.Integer=숫자를 입력해주세요.
typeMismatch=타입 오류입니다.
Validator 분리1
Validator 인터페이스
public interface Validator {
boolean supports(Class<?> clazz);
void validate(Object target, Errors errors);
}
• supports() : 해당 검증기를 지원하는 여부 확인(뒤에서 설명)
• validate(Object target, Errors errors) : 검증 대상 객체와 BindingResult
Validator 분리2
스프링이 Validator 인터페이스를 별도로 제공하는 이유는 체계적으로 검증 기능을 도입하기 위해서다.
그런데 앞에서는 검증기를 직접 불러서 사용했고, 이렇게 사용해도 된다. 그런데 Validator 인터페이스를
사용해서 검증기를 만들면 스프링의 추가적인 도움을 받을 수 있다.
WebDataBinder
@InitBinder
public void init(WebDataBinder dataBinder) {
log.info("init binder {}", dataBinder);
dataBinder.addValidators(itemValidator);
}
• WebDataBinder는 스프링의 파라미터 바인딩의 역할을 해주고 검증 기능도 내부에 포함한다.
• 이렇게 WebDataBinder 에 검증기를 추가하면 해당 컨트롤러에서는 검증기를 자동으로 적용할 수 있다.
@InitBinder → 해당 컨트롤러에만 영향을 준다. 글로벌 설정은 별도로 해야한다
@Validated
• 이 애노테이션이 붙으면 앞서 WebDateBinder에 등록한 검증기를 찾아서 실행
• 그런데 여러 검증기를 등록한다면 각 검증기의 supports() 사용하여 구분
• 아래와 같은 검증기에서는 supports(Item.class)가 호출되고, 결과가 true이므로 ItemValidator의 validate()가 호출된다.
@Component
public class ItemValidator implements Validator {
@Override
public boolean supports(Class<?> clazz) {
return Item.class.isAssignableFrom(clazz);
}
@Override
public void validate(Object target, Errors errors) {...}
}
글로벌 설정
@SpringBootApplication
public class ItemServiceApplication implements WebMvcConfigurer {
public static void main(String[] args) {
SpringApplication.run(ItemServiceApplication.class, args);
}
@Override
public Validator getValidator() {
return new ItemValidator();
}
}
주의
• 글로벌 설정을 하면 다음에 설명할 BeanValidator가 자동 등록되지 않는다.
• 참고로 글로벌 설정을 직접 사용하는 경우는 드물다.
'스프링 > 스프링 MVC 패턴 2편' 카테고리의 다른 글
5. 검증2 - Bean Validation (0) | 2022.12.01 |
---|---|
3. 메시지, 국제화 (0) | 2022.11.29 |
2. 타임 리프 - 스프링 통합과 폼 (0) | 2022.11.28 |
1. 타임리프 - 기본 기능 (0) | 2022.10.28 |