위 글 이후로 오랜만에 템플릿 엔진 관련 글을 쓴다.
타임리프를 사용한 프로젝트를 하나 끝내고 쓰는 회고이다.
최종 안내를 마치고 간단하게 정리하는 목적 및 열정 있게 블로그를 쓰는 나의 모습을 느끼기 위함이 기재 목적이다.
타임리프는 자바 기반의 서버 사이드 템플릿 엔진이다.
두괄식으로 타임리프의 장점을 요약하자면
1. 템플릿 엔진의 자연스러운 사용
2. 표현식의 강력함
3. 다양한 기능 지원
4. 스프링과의 통합
을 장점으로 말할 수 있다.
타임리프는 Spring 기반 프로젝트일때 주로 사용을 하는데, 레거시보다는 부트 기반으로 많이 쓰는 것 같다. (개인 체험)
기본적으로는 HTML 형태를 유지하면서 동적인 웹 페이지를 생성하는 것이 목적이다.
[템플릿 자체를 브라우저에서 직접 열어도 문제가 없다는 것이 큰 장점이다.]
1. HTML 파일을 그대로 유지해서 브라우저에서 직접 열 수 있도록 지원한다.
: 협업도 용이하게 하는 것이 목표이다.
2. 서버 사이드의 데이터를 조작하기 용이하도록 표현식 문법을 지원한다.
: 아래와 같은 형식이다.
변수 표현식: ${...}
선택 변수 표현식: *{...}
메시지 표현식: #{...}
링크 표현식: @{...}
조각 표현식: ~{...}
3. 자체 태그를 정의할 수가 있어서 확장성이 좋다.
: div 내에 th: 로 시작하는 것을 볼 경우에는 타임리프일 확률이 크다.
재사용 목적으로 템플릿 조각을 사용할 수 있는 기능을 제공한다.
반복문/조건문도 each/if 등을 지원해서 동적 컨텐츠 생성 시에 도움이 된다.
4. Spring 에서 사용하기가 좋다.
5. 다국어 지원이 가능하다. (유지보수 시에 굉장히 많이 확인 필요! 서버가 바라보고 있는 message가 1개가 아닐 수 있다!!!! 숙지!!! 디버깅 시 확인 필요!!!!)
: messages.properties 같은 경우가 타임리프 형식이다.
6. form 데이터를 처리/검증하기 좋다.
: 폼 데이터 바인딩/검증을 위한 기능을 제공한다.
서버 사이드 - 클라이언트 사이드 간 처리가 필요하다.
6-1. 바인딩 목적
1) 폼 필드랑 매핑할 목적으로 모델 클래스를 정의한다.
2) 컨트롤러에서 폼 데이터를 처리하는 메소드를 정의한다.
3) 폼에서 th:object, th:field가 들어간 폼을 html 등에서 작성한다.
1 2 3 4 5 6 7 8 9 | <form th:action="@{/forsubmitform}" th:object="${submituser}" method="post"> <div> <label for="name">Name:</label> <input type="text" id="name" th:field="*{name}" /> </div> <div> <input type="submit" value="submit" /> </div> </form> | cs |
4) 폼 submit 후 결과 페이지를 작성한다.
6-2. 검증 목적
1) pom.xml에 의존성을 추가한다.
1 2 3 4 | <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> | cs |
2) 모델 클래스에 검증 어노테이션을 추가한다.
: 보통 @NotEmpty 같이 기재가 되어 있다.
3) 컨트롤러에서 폼 데이터를 검증하는 로직을 추가하고, 에러 메시지도 정의한다.
4) 폼 자체에서 에러 메시지를 표시할 수 있도록 정의한다.
: th:errors 같은 부분을 확인하면 된다.
다국어 지원 관련해서 보통 messages_ko.propreties 와 같이 국적을 붙이는 경우가 많은데, 기본 메시지 소스를 application.properties 쪽에 기재해 놓은 경우도 있지만, 이상하게 설정을 할 수도 있으므로 꼭 확인이 필요하다.
수정을 했는데 반영이 안 될 경우 docker 문제가 아닐 경우도 있다는 것...😂
1. 파일 로드가 안 되는지 확인
2. 파일 경로가 이상한 곳을 바라보고 있는지 확인
3. 임시 데이터를 지워보고 재생성 되는지 확인
4. 로케일 설정 자체가 문제인지 확인 (spring boot 쪽 확인이 필요하다.)
5. 메시지 키 자체가 누락이 되었는지 확인! (수정 시 오류인데 보통 형상관리 할 경우에는 코드리뷰 수준에서 걸러질 것이다.)
6. 캐싱 문제 확인 (spring messages의 cache-duration을 0으로 둬 보고 확인 해 보면 된다.)
7. 메시지 표현식에 오타가 있는지 확인 (수정 시 오류인데 인코딩 문제로 체크가 안 되었을 수 있다.)
8. 그 외 다양한 문제
인프라 엔지니어를 믿지 말고 백엔드 개발 수준에서 처리 할 수 있는 부분은 다 해보고 문제를 삼도록 하자. 😀
근데 이번 프로젝트는 devops 같이 일해서 그냥 체크 잘 하고 끝냈다.
협업 시 [그 동안 잘 돌아가던 타인 설정]을 너무 믿지 말 것을 배웠다.
본문과 상관 없는 사담.
오랜만에 블로그 이름을 바꿨다.
구 : 입금후 변신하는 헐리우드 코딩 스타
신 : 내국인근로자 (정보통신업)
바꾼 이유 : 아래와 같은 느낌의 유머였는데, 블로그 보여주는 사람마다 매번 설명을 해야 해서 잘못되었다고 생각했다! (n년만의 깨달음)
의도한 점 : 돈 받으면 느슨하지 않게 열심히 일하는 헐리우드 스타 같은 느낌
느끼신 점 : 돈 받으면 변심하는 느낌 (충격! 😥)
따라서 직관적인 이름으로 변경했다.
안녕하세요.
한국에서 일하는 정보통신업 근로자 입니다...
성실 이력...
사진 출처는 위에서 [아래]를 누르면 된다. 😀
댓글
댓글 쓰기