템플릿 엔진을 사용하는 이유는 무엇입니까? jsp include 및 jstl 대 타일, freemarker, 속도, 사이트 메쉬

내 뷰를 구성하는 방법을 선택하려고합니다 (spring-mvc를 사용하지만 그다지 중요하지 않습니다)

내가보기에 6 가지 옵션이 있습니다 (상호 배타적이지는 않지만).

• 타일
• Sitemesh
• Freemarker
• 속도
• <jsp:include>
• <%@ include file="..">

타일 과 Sitemesh 를 그룹화 할 수 있습니다. Freemarker 와 Velocity도 마찬가지 입니다. 이 토론의 문제가 아닌 각 그룹 내에서 어느 것을 사용할 것인지에 대한 충분한 질문과 토론이 있습니다.

이것은 흥미로운 읽기 이지만 타일을 사용하도록 설득 할 수는 없습니다.

내 질문은- 이 프레임 워크가 <@ include file=".."> JSTL 로 제대로 수행 할 수없는 것을 제공하는 것입니다 . 요점 (일부는 기사에서 발췌) :

1. 머리글 및 바닥 글과 같은 페이지의 일부를 포함하면 다음과 같은 차이점이 없습니다.

   <%@ include file="header.jsp" %>

   과

   <tiles:insert page="header.jsp" />

2. 제목, 메타 태그 등과 같은 헤더에 매개 변수를 정의합니다 . 이것은 특히 SEO 관점에서 매우 중요합니다. 템플릿 옵션을 사용하면 각 페이지에서 정의해야하는 자리 표시자를 간단히 정의 할 수 있습니다. 그러나 (포함 페이지에서) 및 (포함 된 페이지에서 ) 사용하여 JSTL 로 jsp에서 할 수 있습니다.<c:set><c:out>

3. 레이아웃 재구성 -메뉴 위로 이동 경로를 이동하거나 다른 측면 패널 위로 로그인 상자를 이동하려는 경우. 페이지 포함 (jsp 포함)이 제대로 구성되지 않은 경우 이러한 경우 모든 단일 페이지를 변경해야 할 수 있습니다. 그러나 레이아웃이 지나치게 복잡하지 않고 일반적인 것을 머리글 / 바닥 글에 넣으면 걱정할 필요가 없습니다.

4. 공통 구성 요소와 특정 콘텐츠 간의 결합 -나는 이것에 대한 문제를 찾지 못했습니다. 일부 조각을 재사용하려면 머리글 / 바닥 글이없는 페이지로 이동하고 필요한 곳에 포함합니다.

5. 효율성 -<%@ include file="file.jsp" %> 한 번 컴파일되기 때문에 다른 무엇보다 효율적입니다. 다른 모든 옵션은 여러 번 구문 분석 / 실행됩니다.

6. 복잡성 -모든 비 jsp 솔루션에는 추가 xml 파일, 추가 포함, 전 처리기 구성 등이 필요합니다. 이것은 학습 곡선이며 더 많은 잠재적 인 실패 지점을 도입합니다. 또한 지원 및 변경이 더 지루합니다. 무슨 일이 일어나고 있는지 이해하기 위해 여러 파일 / 구성을 확인해야합니다.

7. 자리 표시 자 -속도 / 자유 마커가 JSTL보다 더 많은 것을 제공합니까? JSTL에서 플레이스 홀더를 입력하고 모델 (컨트롤러에 의해 요청 또는 세션 범위에 배치됨)을 사용하여 이러한 플레이스 홀더를 채 웁니다.

따라서 일반 JSP 대신 /에 추가하여 위의 프레임 워크 중 하나를 사용해야한다고 설득하십시오.

Velocity에 대한 몇 가지 주장 (저는 Freemarker를 사용하지 않았습니다) :

• 이메일 전송과 같은 웹 컨텍스트 외부에서 템플릿 재사용 가능성
• Velocity의 템플릿 언어 구문은 JSP EL 또는 태그 라이브러리보다 훨씬 간단합니다.
• 다른 종류의 논리와 뷰 논리를 엄격하게 분리합니다. 스크립틀릿 태그를 사용하고 템플릿에서 불쾌한 작업을 수행하는 옵션이 없습니다.

자리 표시 자-Velocity / Freemaker가 JSTL보다 더 많은 것을 제공합니까? JSTL에서는 플레이스 홀더를 배치하고 모델 (컨트롤러에 의해 요청 또는 세션 범위에 배치됨)을 사용하여 이러한 플레이스 홀더를 채 웁니다.

예, 참조 는 실제로 VTL의 핵심입니다.

<b>Hello $username!</b>

또는

#if($listFromModel.size() > 1)
    You have many entries!
#end

효율성- <%@ include file="file.jsp" %>한 번 컴파일되기 때문에 다른 무엇보다 효율적입니다. 다른 모든 옵션은 여러 번 구문 분석 / 실행됩니다.

이 점에 동의하거나 이해하는지 잘 모르겠습니다. Velocity에는 템플릿을 캐시하는 옵션이 있습니다. 즉, 템플릿이 구문 분석되는 추상 구문 트리는 매번 디스크에서 읽는 것이 아니라 캐시됩니다. 어느 쪽이든 (그리고 나는 이것에 대한 확실한 숫자가 없습니다), Velocity는 항상 저에게 빠르다고 느꼈습니다 .

레이아웃 재구성-메뉴 위로 이동 경로를 이동하거나 다른 측면 패널 위로 로그인 상자를 이동하려는 경우. 페이지 포함 (jsp 포함)이 제대로 구성되지 않은 경우 이러한 경우 모든 단일 페이지를 변경해야 할 수 있습니다. 그러나 레이아웃이 지나치게 복잡하지 않고 일반적인 것을 머리글 / 바닥 글에 넣으면 걱정할 필요가 없습니다.

차이점은 JSP 접근 방식을 사용하면 동일한 머리글 / 바닥 글을 사용하는 모든 JSP 파일에서이 레이아웃을 재구성하지 않습니까? Tiles 및 SiteMesh를 사용하면 기본 레이아웃 페이지 (JSP, Velocity 템플릿 등-둘 다 중심에있는 JSP 프레임 워크)를 지정할 수 있습니다. 여기서 원하는 내용을 지정한 다음 기본 콘텐츠에 대한 "콘텐츠"조각 / 템플릿에 위임 할 수 있습니다. . 이는 헤더를 이동할 파일이 하나만 있음을 의미합니다.

선택 사이 jsp:include및 타일 / 통해 Sitemesh / 등 사이의 선택을 단순하고 전력 개발자가 모든 시간을 직면. 물론, 파일이 적거나 레이아웃이 자주 변경되지 않을 것으로 예상하는 경우 jstl및 jsp:include.

그러나 응용 프로그램은 점진적으로 성장할 수있는 방법이 있으며 "새로운 개발을 중지하고 타일 (또는 다른 솔루션)을 개조하여 향후 문제를보다 쉽게 ​​해결할 수 있도록" 을 정당화하기 어려울 수 있습니다 . 처음에는 복잡한 솔루션입니다.

애플리케이션이 항상 단순하게 유지되거나 애플리케이션 복잡성에 대한 벤치 마크를 설정 한 후 더 복잡한 솔루션 중 하나를 통합 할 수 있다면 타일 / 등을 사용하지 않는 것이 좋습니다. 그렇지 않으면 처음부터 사용하십시오.

다른 기술을 사용하도록 설득하지 않겠습니다. 내가 아는 모든 사람들은 JSP가 작동한다면 그냥 고수해야합니다.

저는 주로 Spring MVC로 작업하며 SiteMesh와 함께 JSP 2+를 찾습니다. 가 완벽하게 일치 합니다.

SiteMesh 2/3

다른 템플릿 엔진의 상속 작업처럼 뷰에 적용 할 데코레이터를 제공합니다. 이러한 기능은 요즘 없이는 작동 할 수 없습니다.

JSP 2 이상

JSP가 템플릿에서 Java 코드를 피하기 어렵게 만들 것이라고 주장하는 사람들은 가짜입니다. 당신은 그렇게해서는 안되며이 버전에서는 그렇게 할 필요가 없습니다. 버전 2는 이전 버전에 비해 큰 장점 인 EL을 사용한 메서드 호출을 지원합니다.

JSTL 태그를 사용하면 코드가 여전히 HTML처럼 보이기 때문에 덜 어색합니다. Spring은 매우 강력한 taglibs를 통해 JSP에 대한 많은 지원을 제공합니다.

taglib는 확장하기가 쉽기 때문에 자신의 환경을 사용자 정의하는 것이 쉽습니다.

JSP 사용에 반대하는 facelet에 대한 가장 좋은 주장 중 하나는 JSP를 사용하는 것에 반대하는 것입니다. 컴파일이 JSP 컴파일러에 위임되는 대신 인터프리터와 통합된다는 것입니다. 즉, 런타임 엔진이 변경 사항을 발견하기 위해 변경 사항을 저장할 때 주변 JSF 태그의 ID 속성을 변경해야하는 JSF 1.1에서 가장 성가신 일 중 하나가 사라져서 절약을 제공합니다. 편집기 내에서 브라우저에서 다시로드, 훨씬 더 나은 오류 메시지와 함께 다시로드합니다.

좋은보기 기술은 대부분의 가장 성가신 if / switch / conditional 문을 제거하지만 단순한 include는 제거하지 않습니다. '복잡한'보기 기술을 사용하면 '단순한'애플리케이션이 생성됩니다.

특정 애플리케이션에 대한 정보를 제공하지 않았습니다. 예를 들어 몇 가지 이유로 JSP를 사용하지 않습니다.

JSP 템플릿에서 Java 코드를 사용하는 것을 피하는 것이 어렵 기 때문에 순수한 뷰의 개념을 깨뜨리고 결과적으로 뷰 및 컨트롤러와 같은 여러 위치에서 코드를 유지하는 데 어려움을 겪을 것입니다.

JSP는 세션을 설정하는 JSP 컨텍스트를 자동으로 생성합니다. 나는 그것을 피하고 싶을 수도 있지만 응용 프로그램이 항상 세션을 사용한다면 문제가되지 않을 수 있습니다.

JSP에는 컴파일이 필요하며 대상 시스템에 Java 컴파일러가없는 경우 사소한 조정은 다른 시스템을 사용한 다음 다시 배포해야합니다.

최소 JSP 엔진은 약 500k의 바이트 코드와 JSTL이므로 임베디드 시스템에 적합하지 않을 수 있습니다.

템플릿 엔진은 JSON 페이로드, 웹 페이지, 이메일 본문, CSV 등과 같은 동일한 모델의 다른 콘텐츠 유형을 생성 할 수 있습니다.

비전문가가 일반 템플릿을 수정하는 데 어려움을 겪지 않았을 때 비 Java 프로그래머는 JSP 템플릿 작업에 어려움을 겪을 수 있습니다.

나는 오래 전에 같은 질문을했고 다른 솔루션에서 본 모든 단점이없는 내 프레임 워크 (확실히 템플릿 엔진 기반)를 작성하여 끝냈습니다. 말할 것도없이 그것은 약 100k의 바이트 코드입니다.

나는 이것이 현명한 대답으로 나온다는 것을 알고 있지만 진실은 현재 프로젝트에서 코드보다 템플릿을 사용하는 것의 이점을 보지 못한다면 아마도 현재 프로젝트에는 하나가 없기 때문일 것입니다. .

그 중 일부는 규모에 관한 것입니다. 포함이 sitemesh처럼 강력하다고 생각할 수 있으며, 적어도 적은 수의 페이지 (아마도 100 페이지 정도)에 대해서는 확실히 사실이지만, 수천 페이지가 있으면 관리 할 수 ​​없게됩니다. (따라서 eBay의 경우 필요하지 않습니다. Salesforce의 경우 아마도 그럴 것입니다)

또한 앞서 언급했듯이 freemarker와 velocity는 서블릿에 한정되지 않습니다. 무엇이든 사용할 수 있습니다 (메일 템플릿, 오프라인 문서 등). freemarker 또는 velocity를 사용하기 위해 Servlet 컨테이너가 필요하지 않습니다.

마지막으로 귀하의 요점 5는 부분적으로 만 사실입니다. 아직 액세스하지 않은 경우 액세스 할 때마다 컴파일됩니다. 즉, 무언가를 변경할 때마다 서블릿 컨테이너 "work"디렉토리를 삭제하여 JSP를 재 컴파일하도록 기억해야합니다. 템플릿 엔진에서는 필요하지 않습니다.

TL; DR Templaing 엔진은 JSP + JSTL의 일부 (인식 또는 실제) 단점을 해결하기 위해 작성되었습니다. 사용 여부는 전적으로 요구 사항과 프로젝트 규모에 따라 다릅니다.