오류 메세지도 일관성 있게 한군데에서 관리해보자 (메세지 국제화 처럼..) 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 객체 생성 시, 파..

서블릿의 예제와 문법은 제외 하겠다. (Spring MVC의 핵심이 되는 컨트롤러 에노테이션 기준으로 서술) @Controller 반환 값이 String이면 View 이름으로 인식, View를 찾고(ViewResolver) View가 렌더링 된다. @RestController 반환 값으로 뷰를 찾는게 아니라, HTTP 메세지 바디에 바로 입력 된다. @RequestMapping method = RequestMethod.GET 과 같이 HTTP 메서드를 지정하지 않을 경우, HTTP Method와 무관하게 모두 적용된다. (GET, HEAD, POST, PUT, PATCH, DELETE) @GetMapping, @PostMapping, @PutMapping, @DeleteMapping, @PatchMapp..