토우지 토우지

애플리케이션에서 폼을 작성할때  숫자 입력을 문자로 하여 검증 오류를 발생 시키면 기본적으로는 오류 화면으로 바로 이동한다. 하지만 이렇게 되면 사용자는 뒤로 가서 다시 폼을 처음부터 입력을 해야한다. 이러면 사용자는 서비스를 사용하는 것을 대부분 포기할 것이다. 웹 서비스는 폼 입력시 오류가 발생한다면 고객이 입력한 데이터를 유지한 상태로 어떤 오류가 발생했는지 친절하게 알려줘야한다. 컨트롤러의 중요한 역할 중 하나는 HTTP 요청이 정상인지 검증하는 것이다. 검증은 크게 클라이언트 검증, 서버 검증으로 나눌 수 있다.클라이언트 검증은 조작할 수 있으므로 보안에 취약하다.서버만으로 검증을 한다면, 즉각적인 고객의 사용성이 부족해진다.둘이 적절히 섞어서 사용하되, 최종적으로 서버 검증은 필수이다.API ..

타임리프는 스프링 없이도 동작하지만, 스프링과 통합을 위해 여러 가지 기능을 제공한다. 스프링 통합으로 추가되는 기능들스프링 SpringEL 문법 통합${@myBean.doSomething()} 처럼 스프링 빈 호출 지원편리한 폼 관리를 위한 추가 속성th:object(기능 강화, 폼 커맨드 객체 선택th:field, th:errors, th:errorclass폼 컴포넌트 기능checkbox, radio button, List 등을 편리하게 사용할 수 있는 기능 지원스프링의 메시지, 국제화 기능의 편리합 통합스프링의 검증, 오류 처리 통합스프링의 변환 서비스 통합(ConversionService)이렇게 많은 기능들을 제공해준다. 지금부터 하나하나씩 어떤 기능들이 있는지 살펴보자. 1. 입력 폼 처리타임리..

1. 반복타임리프에서 반복은 th:each를 사용한다. 추가로 반복해서 사용할 수 있는 여러 상태 값을 지원한다. username age userCount username age index = count = size = even? = odd? = first? = last? = current =  반복 기능반복시 오른쪽 컬렉션 (${user}) 의 값을 하나씩 꺼내서 왼쪽 변수 (user) 에 담아서 태그를 반복 실행한다.th:each는 List 뿐만 아니라 java.util.Iterable, java.util.Enumeration을 구현한 모든 객체를 반복에 사용할 수..

타임리프의 특징은 크게 3가지가 있다.타임리프 특징서버 사이드 HTML 렌더링(SSR)네츄럴 템플릿스프링 통합 지원1. 서버 사이드 HTML 랜더링(SSR)타임리프는 백엔드 서버에서 HTML을 동적으로 렌더링 하는 용도로 사용된다.2. 네츄럴 템플릿타임리프는 순수 HTML을 최대한 유지하는 특징을 가지고 있다.타임리프로 작성한 파일은 HTML을 유지하기 때문에 웹 브라우저에서 파일을 직접 열어도 내용을 확인할 수 있고, 서버를 통해 뷰 템플릿을 거치면 변경된 결과를 확인할 수 있다.(JSP같은 경우에는 웹 브라우저에서 파일을 직접 열면 깨짐, JSP는 오직 서버를 통해 JSP가 렌더링 되고 HTML 응답 결과를 받아야 화면을 확인할 수 있다.이렇게 순수 HTML을 그대로 유지하면서 뷰 템플릿도 사용할 수..

우리가 HTTP BODY에서 메시지(String, Json)를 읽어 들일때 주로 @RequestBody, HTTP BODY에 메시지를 작성할 때 주로 @ResponseBody를 사용한다. 이때 메시지 바디에 있는 내용을 HTTP 메시지 컨버터를 사용한다. HTTP 메시지 컨버터 인터페이스 HTTP 메시지 컨버터는 HTTP 요청, HTTP 응답 둘 다 사용된다. canRead(), canWrite() : 메시지 컨버터가 해당 클래스, 미디어타입을 지원하는지 체크 read(), write() : 메시지 컨버터를 통해서 메시지를 읽고 쓰는 기능 스프링 부트 기본 메시지 컨버터 스프링 부트는 다양한 메시지 컨버터를 제공하는데, 대상 클래스 타입과 미디어 타입 둘을 체크해서 사용여부를 결정한다. ByteArray..

스프링 MVC 전체 구조 스프링 MVC은 프론트 컨트롤러 패턴과 어댑터 패턴으로 구현되어 있다. 스프링 MVC의 프론트 컨트롤러가 디스패처 서블릿(Dispatcher Servlet)이다. DispatcherServlet은 부모 클래스에서 HttpServlet을 상속 받아서 사용하고, 서블릿으로 동작한다. 스프링 부트는 DispatcherServlet을 서블릿으로 자동으로 등록하면서 모든 경로(urlPatterns="/")에 대해서 매핑한다. 요청 흐름을 살펴보면 첫번째로 서블릿이 호출되면 HttpServlet이 제공하는 service()가 호출된다. 스프링 MVC는 DispatcherServlet의 부모인 FrameworkServlet에서 service()를 오버라이드 해두었다. FrameworkServ..

전 포스트에서 MVC 패턴으로 바꾼 코드를 프론트 컨트롤러 패턴을 적용하여 스프링 MVC와 비슷한 구조로 변경해 볼 것이다. 이전 일부 코드는 다음과 같다. 기존의 코드는 HttpServlet 클래스를 사용하고 있었는데 단점이 존재하였다. View 호출을 위한 dispatcher, forward, viewPath 중복 HttpServletRequest, HttpServletResponse 가 무조건 사용되는 것이 아님. 미사용 코드가 발생 각 컨트롤러에서 공통 처리가 어려움 이런 단점을 없애기 위해 프론트 컨트롤러 패턴을 적용하여 V1을 만들어 보았다. 프론트 컨트롤러 V1 구조 위 코드는 기존 Servlet, JSP 호출하는 코드는 유지하고 FrontControllerServletV1의 프론트 컨트롤러..

서블릿과 JSP의 한계 서블릿으로 개발할 때는 뷰(View) 화면을 위한 HTML을 만드는 작업이 자바 코드에 섞여서 지저분하고 복잡하다. 이를 해결하기 위해 JSP를 사용하면 뷰를 생성하는 HTML 작업을 깔끔하게 가져가고, 중간에 동적으로 변경이 필요한 부분에만 자바 코드를 적용했다. 오른쪽 사진을 보면 코드의 상위의 절반은 회원을 저장하기 위한 비즈니스 로직이고 그 아래 코드는 HTML로 보여주기 위한 뷰 영역이다. 이 코드를 보면 JAVA 코드, 데이터를 조회하는 리포지토리 등등 다양한 코드가 모두 JSP에 노출되어 있다. 지금은 작은 프로젝트라 한눈에 보이지 만약 대형 프로젝트라면 유지 보수가 힘들 것이다. 비즈니스 로직을 호출하는 부분에 변경이 발생해도 해당 코드를 손대야 하고, UI를 변경할..