본문 바로가기
✨ Back-end/etc

[Spring] 검증(Validation) -4, rejectValue()와 typeMismatch

by 환풍 2023. 10. 5.
728x90

 

 

[Spring] 검증(Validation) -3 , FieldError와 properties값 가져오기

[Spring] 검증(Validation) -2 BindingResult MemberController BindingResult 데이터 바인딩 과정에서 발생하는 검증 오류를 보유하고 있는 객체이다. 주로 폼 데이터를 도메인 객체에 바인딩할 때 사용된다. 예를

bright-landscape.tistory.com

rejectValue() , reject() 를 사용하면 FieldError , ObjectError를 직접 생성하지 않고, 깔끔하게 검증 오류를 다룰 수 있다.

rejectValue() 는 FieldError 이고 reject() 는 ObjectError이다.

 

rejectValue(@Nullable String field, String errorCode, @Nullable Object[] errorArgs, @Nullable String defaultMessage);
  • field : 오류 필드명
  • errorCode : 오류 코드(이 오류 코드는 메시지에 등록된 코드가 아니다. 뒤에서 설명할 messageResolver를 위한 오류 코드이다.)
  • errorArgs : 오류 메시지에서 {0} 을 치환하기 위한 값
  • defaultMessage : 오류 메시지를 찾을 수 없을 때 사용하는 기본 메시지

 

 

bindingResult.addError(new FieldError("memberVO", "memId", memberVO.getMemId(), false, new String[] {"required.item.itemName"}, null, "* 아이디는 필수 항목."));

저렇게 길었던 코드들을

Controller

위와 같이 저렇게 바꿔줄 수 있다.

bindingResult는 이미 objectName을 알고 있다. 

 

errors.properties

반드시 memberVO 처럼 오브젝트 명. memId 처럼 필드 명 을 명시해주어야 작동한다.

또, reqired나 range만 작성하면서 단순하게 만들어줄 수도 있다. 범용성을 높여주는 것이다.

 

컨트롤러에서 "required"나 "range" 자리와 같이

errorCode에 해당하는 자리에 errors.properties에 있는 앞글자만 따와주었는데, 왜 이렇게만 해도 동작이 될까?

 

Controller

그리고 required는 *need required인데 왜 required.memberVO.memId에 있는 *Product name is required가 될까?

 

errors.properties

Level1부터 찾고, 만약 Level1과 같은 디테일 메시지가 없으면 Level2  이렇게 실행되는 것이다.

Level3에 있는 java.lang.String과 같이 문자열 오류도 표기할 수 있다.


typeMismatch 

또한 스프링에서 메시지 코드가 없을 경우 스프링이 생성한 기본 메시지가 실행되는데,

이때 typeMismatch를 사용하면 된다. 이는 스프링이 직접 만든 에러표현이다.

errors.properties에 typeMismatch = *type error를 추가하면 긴 코드가 나오지 않고 설정한 에러구문이 나온걸 볼 수 있다.

반응형

댓글