Hansel

Bean Validation으로 검증하는 방법은 매우 편리하지만 한계가 존재한다. 등록하는 폼과 수정하는 폼의 요구사항이 다르다면 단순한 방법으로 처리하기엔 무리가 있다. 따라서 실제 객체와 생성 폼, 수정 폼은 분리해서 검증하는 방법을 사용해야한다. 생성폼과 수정폼을 위한 클래스 생성 DTO를 사용하여 생성과 수정을 나눈다. 컨트롤러에선 생성, 수정 객체를 ModelAttribute로 데이터를 받아와 생성해 검증을 하고 해당 DTO를 실제 엔티티로 변환하여 저장한다. ModelAttribute 주의사항 해당 어노테이션은 해당 객체의 클래스 이름을 받아와 모델을 생성하기 때문에 이 점에 유의해서 이름을 설정하거나 하지 않는 방향을 잘 잡아야한다.

더 편한 검증처리 이전 글에서는 BindingResult의 FieldError 혹은 rejectValue 등을 사용한 에러처리 방법을 보았다. 하지만 그 방법들 또한 여러 파라미터를 처리해야하는 문제로 귀찮은 점이 분명 존재한다. 조금 더 편하게 에러를 검증할 수 있는 방법이 존재한다. Bean Validation 공식 사이트: http://hibernate.org/validator/ 공식 메뉴얼: https://docs.jboss.org/hibernate/validator/6.2/reference/en-US/html_single/ 검증 애노테이션 모음: https://docs.jboss.org/hibernate/validator/6.2/reference/en-US/ The Bean Validation ..

Validator 컨트롤러에서 검증 로직이 차지하는 부분은 매우 크다. 이런 경우 별도의 클래스로 역할을 분리하는 것이 좋다. 그리고 이렇게 분리한 검증 로직을 재사용 할 수도 있다. supports() {} : 해당 검증기를 지원하는 여부 확인 validate(Object target, Errors errors) : 검증 대상 객체와 BindingResult Validator 사용 기존에 있던 에러 검증 코드는 모두 Validator한테 넘겨줬고 이제는 호출만 하면 된다. @WebDataBinder => WebDataBinder 는 스프링의 파라미터 바인딩의 역할을 해주고 검증 기능도 내부에 포함한다. 이렇게 WebDataBinder 에 검증기를 추가하면 해당 컨트롤러에서는 검증기를 자동으로 적용할 수..

이전까지는 각각의 파라미터에 맞는 타입과 데이터들을 넣어 에러를 처리했다. 하지만 FieldError와 ObjectError를 모두 신경쓰고 파라미터 하나하나 맞춰주는건 생각보다 귀찮은 일이다. 간소화 / rejectValue 컨트롤러에서 BindingResult 는 검증해야 할 객체인 target 바로 다음에 온다. 따라서 BindingResult 는 이미 본인이 검증해야 할 객체인 target 을 알고 있다. BindingResult 가 제공하는 rejectValue() , reject() 를 사용하면 FieldError , ObjectError 를 직접 생성하지 않고, 깔끔하게 검증 오류를 다룰 수 있다. rejectValue의 파라미터는 다음과 같다. void rejectValue(@Nullabl..

검증이 왜 필요한가 웹 서비스는 폼 입력시 오류가 발생하면, 고객이 입력한 데이터를 유지한 상태로 어떤 오류가 발생했는지 친절하게 알려주어야 한다 컨트롤러의 중요한 역할중 하나는 HTTP 요청이 정상인지 검증하는 것이다. 클라이언트 검증은 조작할 수 있으므로 보안에 취약하다. 서버만으로 검증하면, 즉각적인 고객 사용성이 부족해진다. 둘을 적절히 섞어서 사용하되, 최종적으로 서버 검증은 필수이다. API 방식을 사용하면 API 스펙을 잘 정의해서 검증 오류를 API 응답 결과에 잘 남겨주어야 함. 검증의 방법 스프링에서 검증은 Errors와 BindingResult를 사용한다. BindingResult 방법이 쉬워 이 방법을 주로 쓰겠지만 Errors 를 상속받는 부모-자식 관계이다. BindingResu..

메세지 상품명이라는 단어를 모두 상품이름으로 고쳐달라고 하면 어떻게 해야할까? 다양한 메시지를 한 곳에서 관리하도록 하는 기능을 메시지 기능이라 한다. 예를 들어서 messages.properteis 라는 메시지 관리용 파일을 만들고 item=상품 item.id=상품 ID item.itemName=상품명 item.price=가격 item.quantity=수량 각 HTML들은 다음과 같이 해당 데이터를 key 값으로 불러서 사용하는 것이다. 스프링은 기본적인 메시지 관리 기능을 제공한다. 1. 메세지를 담당하는 messages.properties 생성 2. 필요한 메세지 작성 및 매핑 타임리프에서는 "#{메세지}" 로 매핑한다. 국제화 메시지에서 설명한 메시지 파일( messages.properteis )..

인프런에서 스프링 MVC 강의를 보는데 JPA를 추가해서 하면 더 재밌겠다는 생각이 들었다. 그래서 무작정 JPA를 적용해서 진행하는데 생각보다 까다로운 문제들이 생긴다. 셀렉트 박스 처리하기 이 사진에서 처럼 서울,부산,제주 등의 셀렉트 박스를 처리해야 한다. 지역을 객체로 생성하고 지역과 상품의 연관관계를 생각해봤다. 하나의 지역에서 다양한 상품이 판매될 수 있고 하나의 상품이 다양한 지역에서 판매될 수 있으니 이 둘의 관계는 (N:M)이 된다. 따라서 중간에 다대다를 해소해주는 테이블이 필요하다. 아이템 엔티티는 이렇게 뽑았다. 중간 테이블인 ItemByRegion과 관계를 잡고 엔티티 내에서 데이터를 변경할 수 있도록 메서드를 작성했다. ItemUpdate는 객체의 기본 필드들의 데이터 변경감지를..

https://www.thymeleaf.org/doc/tutorials/3.0/thymeleafspring.html Tutorial: Thymeleaf + Spring Preface This tutorial explains how Thymeleaf can be integrated with the Spring Framework, especially (but not only) Spring MVC. Note that Thymeleaf has integrations for both versions 3.x and 4.x of the Spring Framework, provided by two separate libraries c www.thymeleaf.org 폼처리 th:object , th:field 를 사용..

리터럴 접근 리터럴의 경우 '*' 처럼 작은 따옴표로 감싸줘야 한다. 예를 들어 처럼 감싸주면 된다. 하지만 위 예시처럼 공백 없이 쭉 이어진다면 하나의 의미있는 토큰으로 인지해서 다음과 같이 작은 따옴표를 생략할 수 있다 이런 예시의 경우 작은 따옴표가 필요하다. 다음과 같이 작은 따옴표가 아닌 '|' 로 리터럴을 처리할 수도 있다. 리터럴 대체 문법을 사용하면 마치 템플릿을 사용하는 것 처럼 편리하다. 속성 값 설정 HTML에서 checked 속성은 checked 속성의 값과 상관없이 checked 라는 속성만 있어도 체크가 된다. 이런 부분이 true , false 값을 주로 사용하는 개발자 입장에서는 불편하다. 타임리프의 th:checked 는 값이 false 인 경우 checked 속성 자체를 ..

인프런의 김영한 강사님 강의를 듣고 작성하는 글입니다. 타임리프란? 타임리프 개념 타임리프는 순수 HTML을 최대한 유지하는 특징이 있다 대부분의 뷰 템플릿들은, 예를 들어 JSP의 경우 해당 파일을 열면, JSP 소스코드와 HTML이 뒤죽박죽 섞여서 웹 브라우저에서 정상적인 HTML 결과를 확인할 수 없다. 오직 서버를 통해서 JSP가 렌더링 되고 HTML 응답 결과를 받아야 화면을 확인할 수 있다. 타임리프는 타임리프가 적용된 파일을 열더라도 정상적으로 HTML이 확인된다. 이렇게 순수 HTML을 그대로 유지하면서 뷰 템플릿도 사용할 수 있는 타임리프의 특징을 네츄럴 템플릿(natural templates)이라 한다. 텍스트 처리 타임리프는 기본적으로 HTML 태그의 속성에 기능을 정의해서 동작한다...