이전 포스팅에서 봤던 검증 로직에서.. BindingResult에 FieldError와 ObjectError를 생성해서 넣는 방식은 너무 파라미터도 많고 힘들다.. BindingResult가 파라미터로 있는 컨트롤러는 위 예시와 같이 검증 대상(Item) 바로 뒤에 위치하게 된다. 그렇다는 말은.. BindingResult는 이미 검증할 대상을 알고 있다는 말이다. (위 예시에서 bindingResult.getObjectName(), bindingResult.getTarget() 을 사용함에서 알 수 있다.) item item 객체 정보 출력 검증 대상을 이미 알고있기 때문에 좀 더 간단하게 검증 로직을 구현할 수 있다. rejectValue(), reject() 좀더 간단한 파라미터를 가지는 걸 볼 수..

오류 메세지도 일관성 있게 한군데에서 관리해보자 (메세지 국제화 처럼..) codes : 메세지 코드 arguments : 메세지에서 사용하는 인자 defaultMessage : 기본 오류 메세지 codes, arguments를 활용하면 메세지 국제화처럼 관리가 된다. (오류 발생시 오류 코드로 메세지를 찾기 위해 사용된다.) errors.properties 라는 별도의 파일을 만들어 관리 가능. application.properties 에 spring .messages.basename=messages, errors 라인 추가 (messages.properties 와 errors.properties 파일을 등록하겠다는 의미) controller> errors.properties>

BindingResult 스프링에서 제공하는 invalid 값이 넘어왔을 때, invalid 값들을 보관하는 객체이다. 해당 컨트롤러에 BindingResult 객체가 @ModelAttribute 파라미터 다음 파라미터로 존재하면, 해당 @ModelAttribute 데이터 바인딩 시 오류가 발생해도 컨트롤러가 호출된다. 위 예시와 같이 @ModelAttribute로 받는 Item 파라미터 다음으로 BindingResult 객채 파라미터가 있어서 타입에러와 같이 Item 바인딩시 오류가 나도 컨트롤러 호출 전에 400 에러 페이지로 가지 않고, 해당 컨트롤러가 호출된다. BindingResult 가 없다 -> 400 오류가 발생하면서 컨트롤러가 호출 되지 않고, 오류 페이지로 이동한다. BindingRes..

validation 1편에서 봤던 controller 의 코드이다. 위 컨트롤러의 문제점은 무엇일까.. 타입 에러가 나면 다시 addFrom 페이지로 돌아가지지 않으며.. 404 에러 페이지가 보여진다. (ex. price 페이지에서 숫자를 입력하지 않고 문자를 입력했을 시..) (Item 객체의 price 타입은 Interger 타입이다. 문자를 보관할 수 없다.) 이유는? 스프링 MVC에서 해당 addItem 컨트롤러에 진입 하기 전에 예외가 발생하기 때문이다. 파라미터로 Item 객체를 넣어줄때는 해당 데이터를 파싱 후, Item 객체로 제공하기 때문 따라서, 컨트롤러가 호출되지도 않는다. 그래서.. 타입 에러가 날때 현재... 유저가 입력한 데이터가 유지되지 않는다.

컨트롤러는 HTTP 요청이 정상인지 검증할 의무가 있다. 위 예시와 같이, /add URL로 addFrom controller를 호출하면 빈 Item 객체를 model 에 넣고 /addFrom 뷰를 보여주는 이유? (참고, /addForm 뷰가 호출되어도 웹브라우저 상에서 컨트롤러가 호출한 /add 라는 URL은 변하지 않는다.) /addForm 뷰에서는 위와 같이 th:object 로 addForm 컨트롤러에서 빈 Item 객체를 출력하고있다 (비어있기 때문에 아무것도 출력하지 않음) 여기서는 의미가 없지만.. 만약에 해당 addForm 뷰에서 HTTP form 방식으로 post 등록 컨트롤러를 호출(값을 채우고 등록버튼 누르기)했을 때, 등록할 값들이 invalid 하다면... add등록을 하지않고 ..

Redirect 클라이언트가 서버로 어떤 요청(A)을 보냈을 경우, 서버가 특정 로직의 결과로 B로 다시 요청을 보내라고 지시하는 것을 의미 한다. (서버 : 클라이언트야 URL 바꿔라!) PRG 방식 Post / Redirect / Get 을 의미 한다. 웹 클라이언트(브라우저)에서 서버로 상품을 등록하는 기능을 예시로 들겠다. (등록 하면, 상품의 상세 뷰가 보인다.) 클라이언트가 Post 메서드 방식으로 서버로 요청을 보내며 상품 등록을 한다. -> 상품 등록(저장) 컨트롤러가 호출된다. -> 컨트롤러에서 상품이 실제 DB에 저장이된다. -> 상품 상세 뷰를 클라이언트에게 보여준다. 클라이언트에서 정상적으로 상품 등록을 마치고 상품 상세 뷰 화면에서 새로고침을 한다. -> 상품이 중복되어 또 등록된..

HTTP 메시지 컨버터에 대하여 알아보자 컨트롤러가 응답을 하는데는 3가지 종류가 있다. ㄱ. 정적 리소스 응답 ㄴ. 뷰 템플릿을 사용한 응답 ㄷ. HTTP Message Body에 직접 데이터를 넣어 응답 이 중에서 뷰 템플릿을 사용한 응답은.. 그림과 같이 viewResolver가 문자열(hello-template)로 반환된 논리적 뷰 이름으로 뷰를 찾아준다. (Thymeleaf의 경우 viewResolver는 ThymeleafViewResolver 이다.) 뷰가 동적으로 렌더링 되어 HTML로 생성되고 웹브라우저에게 응답으로 내려준다. 하지만, HTTP Message Body에 직접 데이터를 넣어 응답 해주는 경우에는.. 위와 같이 @ResponseBody가 사용되며, viewResolver가 사용..

Spring에서는 요청과 마찬가지로 응답을 만드는 방법도 3가지이다. ㄱ. 정적 리소스 응답 //파일을 그대로 전달 ㄴ. 뷰 템플릿 사용 //동적인 HTML 응답 (SSR) ㄷ. HTTP 메시지 사용 //응답 HTTP Message Body에 직접 데이터 전달 ㄱ. 정적 리소스 응답 정적 리소스의 경로 -> 스프링 부트는 아래 디렉토리에 있는 정적 리소스를 제공한다. /static, /public, /resources, /META-INF/resources ㄴ. 뷰 템플릿 사용한 응답 뷰 템플릿을 거쳐서 HTML이 생성, 뷰가 응답을 만들어 전달한다. (뷰 템플릿이 만들 수 있는 모든 것) src/main/resources/templates ModelAndView ModelAndView 객체 생성 시, 파..