Spring 템플릿 엔진, mustache

템플릿 엔진

지정된 템플릿 양식과 데이터가 합쳐져 HTML문서를 출력하는 소프트웨어

- 서버 템플릿 엔진 : JSP, Freemarker, 서버에서 구동됨.

서버 템플릿 엔진을 이용한 화면 생성은 서버에서 Java 코드로 문자열을 만든 뒤 이 문자열을 HTML로 변환하여 브라우저로 전달

서버 > Java 문자열 > HTML > 브라우저

서버 템플릿 엔진

- 클라이언트 템플릿 엔진 : React, View의 View 파일들

자바스크립트는 브라우저 위에서 작동, 자바스크립트 코드가 실행되는 장소는 서버가 아닌 브라우저

Vue.js나 React.js를 이용한 SPA(Single Page Application)는 브라우저에서 화면을 생성, 즉, 서버에서 이미 코드가 벗어난 경우이며 서버에서는 Json 혹은 Xml형식의 데이터만 전달하고 클라이언트에서 조립함.

(최근에는 서버 사이드 렌더링 지원, 자바스크립트 프레임워크의 화면 생성 방식을 서버에서 실행하는 것, 시작단계에서는 스트링 부트와 자바스크립트 서버사이드에서 렌드링 구현 비추천)

 

머스테치

수많은 언어를 지원하는 가장 심플한 템플릿 엔진(JSP와 같이 HTML을 만들어 주는 템플릿 엔진)

자바에서 사용될 때는 서버 템플릿 엔진으로, 자바스크립트에서 사용될 때는 클라이언트 템플릿 엔진으로 모두 사용 가능

 

자바 진영에는 JSP, Velocitym, Freemarker, Thymelear등 다양한 서버 템플릿 엔진 존재

 

-JSP, Velocity: 스프링 부트에서는 권장하지 않는 템플릿 엔진

-Freemarker 템플릿 엔진으로는 과한 기능 지원

-Thymeleaf 스프링에서 밀고 있으나 문법이 어려움. HTML 태그에 속성으로 템플릿 기능을 사용하는 방식

태그 속성 방식

 

머스테치의 장점은 문법 심플, 로직 코드를 사용할 수 없어 View의 역할과 서버의 역할이 명확하게 분리됨.

Mustache.js와 Mustache.java의 2가지가 다 있어 하나의 문법으로 클라이언트/서버 템플릿 모두 사용 가능

 

-템플릿 엔진은 화면 역할에만 충실해야 함, 너무 많은 기능을 제공하면 API와 템플릿 엔진, 자바스크립트가 서로 로직을 나눠 갖게 되어 유지보수하기가 굉장히 어려움.

 

-Thymeleaf나 JSP등은 커뮤니티 버전에서 지원하지 않고 유료버전에서만, 머스테치는 인텔리제이 커뮤니티 버전을 사용해도 플러그인 사용 가능

 

머스테치 스타터 덕분에 문자열을 반환할 때 앞의 경로와 뒤의 파일 확장자는 자동으로 지정됨.

앞의 경로는 src/main/resources/templates로, 뒤의 파일 확장자는 .mustache가 붙는 것.

"index"를 반환하므로, src/main.resources/tempates/index.mustache로 전환되어 View Resolver가 처리하게 됨.

 

---

게시물 등록 화면 만들기

부트스트랩, 제이쿼리 등 프론트엔드 라이브러리를 사용할 수 있는 방법

1. 외부 CDN 사용

2. 직접 라이브러리를 받아서 사용하는 방법 (npm/bower/yarn+grunt/hulp/webpack)

 

-레이아웃 방식

공통 영역을 별도의 파일로 분리하여 필요한 곳에서 가져다 쓰는 방식

(머스테치 화면에 어디서나 필요한데 매번 해당 라이브버리를 머스테치 파일에 추가하기엔 번거로움)

 

-bootstrap.js 제이쿼리가 꼭 있어야함 - bootstrap.js가 제이쿼리에 의존함.

 

-{{> }}는 현재 머스테치 파일을 기준으로 다른 파일을 가져옴.

 

index.mustacge에서 a.js가 추가되어 a.js도 a.js만의 init과 save function이 있다면?

브라우저의 스코프는 공용 공간으로 쓰이기 때문에 나중에 로딩된 js의 init, save가 먼저 로딩된 js의 function을 덮어쓰게 됨.

여러 사람이 참여하는 프로젝트에서는 중복된 함수 이름은 자주 발생할 수 있기 때문에 모든 function 이름을 확인하면서 만들 수 없음.

이런 문제를 피하기 위해 index.js만의 유효범위를 만들어 사용

-var index이란 객체를 만들어 해당 객체에서 필요한 모든 function을 선언하는 것. 이렇게 하면 index 객체 안에서만 function이 유효하기 때문에 다른 JS와 겹칠 위험이 사라짐(ES6)

 

스프링 부트는 기본적으로 src/main/resources/static에 위치한 자바스크립트, CSS, 이미지 등 정적 파일들을 URL에서 /로 설정됨.

 

머스테치 문법

{{#posts}}

posts라는 List 순회, Java의 for문과 동일하게 생각

{{id}}등의 {{변수명}}

List에서 뽑아낸 객체의 필드 사용

 

-규모가 있는 프로젝트에서 데이터 조회는 FK의 조인, 복잡한 조건 등으로 인해 이런 Entity 클래스만으로 처리하기 어려워 조회용 프레임워크를 추가로 사용 대표적으로 querydsl, jooq, MyBatis 등이 있음.

조회는 위 3가지 프레임워크 중 하나를 통해 조회, 등록/수정/삭제 등은 SpringDataJpa를 통해 진행, querydsl 추천

 

Querydsl

타입 안정성 보장 - 단순한 문자열이 아닌 메소드 기반으로 쿼리 생성하기 때문에 오타나 존재하지 않는 컬럼명을 명시할 경우 IDE에서 자동으로 검출됨. MyBatis에서는 지원하지 않음

많은 회사에서 사용 중 (JPA 사용하는)

레퍼런스가 많음

 

람다식

.map(PostsListResponseDto::new)

.map(posts -> new PostsListResponseDto(posts))

postsRespository 결과로 넘어온 Posts의 stream을 map을 통해 PostsListResponseDto로 변환 -> List로 변환하는 메소드

 

위 오류로 계속 헤맸는데 posts-update.mustache에서 내용 태그에서 잘못 입력해서 났던 거였다.

posts-save.mustache에서도 오타 수정하였다. (500에러)

 

게시판 화면, 게시글 등록화면

게시글 등록

게시글 수정

게시글 삭제

 

/h2-console을 통해 POSTS 테이블에 해당 데이터가 등록되어 조회되는 것을 알 수 있다.

4장에서 배운 것

-서버 템플릿 엔진과 클라이언트 템플릿 엔진의 차이

-머스테치의 기본 사용 방법

-js/css 선언 위치를 다르게 하여 웹사이트의 로딩 속도를 향상하는 방법

-js 객체를 이용하여 브라우저의 전역 변수 충돌 문제를 회피하는 방법