내가 왜 템플리팅 엔진을 쓰겠어?jsp include 및 jstl vs 타일, 프리마커, 속도, 시트메쉬
뷰를 정리하는 방법을 선택하려고 합니다(spring-mvc를 사용하는 경우, 그것은 그다지 중요하지 않습니다).
제가 보기엔 6가지 옵션이 있습니다(서로 배타적인 것은 아니지만).
- 타일
- 시트메쉬
- 프리마커
- 속도
<jsp:include><%@ include file="..">
타일과 Sitemesh는 그룹화할 수 있습니다.Freemarker와 Velocity도 그룹화할 수 있습니다.각 그룹 내에서 어느 것을 사용할지는 이 논의의 문제가 아닙니다. 이에 대한 충분한 질문과 논의가 있습니다.
재미있는 읽을거리지만 타일을 사용하도록 설득할 수 없다.
질문입니다.이러한 프레임워크는 무엇을 제공하는가? <@ include file=".."> JSTL JSTL 。주기기기기기기기기 。
머리글 및 바닥글과 같은 페이지 부분을 포함하면 다음 항목과 차이가 없습니다.
<%@ include file="header.jsp" %>그리고.
<tiles:insert page="header.jsp" />제목, 메타 태그 등 헤더에 매개 변수 정의이것은 특히 SEO의 관점에서 매우 중요합니다.템플리트 옵션을 사용하면 각 페이지에서 정의해야 하는 자리 표시자를 간단히 정의할 수 있습니다.JSTL에서는 JSTL을 사용하여
<c:set>및 (포함 페이지)<c:out>(부속 페이지)레이아웃 재구성 - 메뉴 위 또는 로그인 상자를 다른 측면 패널 위로 이동하려는 경우.페이지 포함 항목(jsp 포함)이 제대로 구성되지 않은 경우 이러한 경우 모든 페이지를 변경해야 할 수 있습니다.그러나 레이아웃이 지나치게 복잡하지 않고 일반적인 내용을 머리글/바닥글에 넣는다면 걱정할 필요가 없습니다.
공통 컴포넌트와 특정 콘텐츠의 결합 - 이 점에 문제가 없습니다.일부 fragment를 재사용하려면 헤더/footer가 포함되지 않은 페이지로 이동하고 필요에 따라 fragment를 포함합니다.
효율성 -
<%@ include file="file.jsp" %>한 번 컴파일되기 때문에 무엇보다 효율적입니다.다른 모든 옵션은 여러 번 구문 분석/실행됩니다.복잡성 - 모든 비jsp 솔루션에는 추가 XML 파일, 추가 포함, 프리프로세서 구성 등이 필요합니다.이는 학습 곡선인 동시에 잠재적인 장애 지점을 더 많이 도입하는 것입니다.또, 서포트나 변경은 귀찮아집니다.무슨 일이 일어나고 있는지를 이해하기 위해서는 다수의 파일이나 구성을 체크할 필요가 있습니다.
플레이스 홀더 - 속도/프리마커가 JSTL보다 더 많은 정보를 제공합니까?JSTL에서는 플레이스 홀더를 배치하고 모델(컨트롤러에 의해 요청 또는 세션 범위에 배치됨)을 사용하여 플레이스 홀더를 채웁니다.
따라서 플레인 JSP가 아닌 위의 프레임워크 중 하나를 사용해야 한다고 설득해 주십시오.
Velocity에 대한 몇 가지 주장(Freemarker를 사용하지 않았습니다).
- 이메일 전송 등 웹 컨텍스트 외부에서 템플릿을 재사용할 수 있는 가능성
- Velocity의 템플릿 언어 구문은 JSP EL 또는 태그 라이브러리보다 훨씬 단순합니다.
- 뷰 로직과 다른 종류의 로직의 엄밀한 분리 - 스크립트렛 태그를 사용하거나 템플릿에서 불쾌한 작업을 수행할 수 있는 옵션이 없습니다.
플레이스 홀더 - 속도/프리메이커는 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 파일에서 이 레이아웃을 재구성해야 하지 않을까요?타일 및 SiteMesh를 사용하면 기본 레이아웃 페이지(JSP, Velocity 템플릿 등)를 지정할 수 있습니다.이 페이지에서는 원하는 내용을 지정한 후 주요 콘텐츠의 "콘텐츠" 단편/템플릿에 위임할 수 있습니다.즉, 헤더를 이동할 수 있는 파일은 1개뿐입니다.
「 」의.jsp:include또한 Tiles/Sitemesh/etc는 개발자들이 항상 직면하는 단순성과 성능 사이에서 선택할 수 있습니다.네, 파일이 적거나 레이아웃이 자주 변경되지 않을 경우jstl ★★★★★★★★★★★★★★★★★」jsp:include.
그러나 애플리케이션에는 점차 증가하는 방법이 있기 때문에 "새로운 개발을 중지하고 타일(또는 기타 솔루션)을 개조하여 미래의 문제를 보다 쉽게 해결할 수 있습니다."라고 정당화하기는 어려울 수 있습니다.이는 처음에 복잡한 솔루션을 사용하지 않는 경우에 필요합니다.
어플리케이션이 항상 심플한 상태로 유지되거나 어플리케이션의 복잡성에 대한 벤치마크를 설정한 후 복잡한 솔루션 중 하나를 통합할 수 있다면 타일 등을 사용하지 않는 것이 좋습니다.그렇지 않으면 처음부터 사용하십시오.
다른 기술을 사용하도록 설득하지는 않을 것입니다.내가 아는 한 모두가 JSP를 고수해야 한다.
저는 주로 봄 MVC에서 일하고 있으며, JSP 2+와 SiteMesh의 조합이 딱 맞는다고 생각합니다.
사이트 메쉬 2/3
다른 템플리트 엔진의 상속 작업처럼 뷰에 적용할 데코레이터를 제공합니다.이러한 기능은 오늘날 없이 작동한다는 것은 상상도 할 수 없는 일입니다.
JSP 2+
JSP가 템플릿에서 자바 코드를 피하기 어렵게 만든다고 주장하는 사람들은 거짓이다.그러면 안 되고 이 버전에서는 그럴 필요가 없습니다.버전 2에서는 EL을 사용한 콜 방식이 지원되고 있습니다.이는 이전 버전에 비해 큰 장점입니다.
JSTL 태그를 붙이면 코드가 HTML처럼 보이기 때문에 어색하지 않습니다.스프링은 매우 강력한 태그립을 통해 JSP에 대한 많은 지원을 제공합니다.
태그립은 확장도 용이하기 때문에 사용자 고유의 환경을 쉽게 맞춤화할 수 있습니다.
JSP를 사용하는 것에 반대하는 페이스렛의 가장 좋은 주장 중 하나는 컴파일러가 JSP 컴파일러에 위임되는 것이 아니라 컴파일러와 통합된다는 것입니다.즉, JSF 1.1에서 겪었던 가장 성가신 일 중 하나는 런타임 엔진이 변경을 검출하기 위해 변경을 저장할 때 주변 JSF 태그의 id 속성을 변경해야 한다는 것입니다.이것에 의해, 보다 뛰어난 에러 메세지와 함께, save-in-editor, reload-in-browser 사이클이 되돌려집니다.
좋은 뷰 테크놀로지를 사용하면, 대부분의 알기 쉬운 if/switch/condition 스테이트먼트를 생략할 수 있습니다.단순한 include는 그렇지 않습니다.'복잡한' 뷰 기술을 사용하면 '간단한' 애플리케이션을 만들 수 있습니다.
특정 응용 프로그램에 대한 정보를 제공하지 않았습니다.예를 들어 JSP를 사용하는 이유는 다음과 같습니다.
JSP 템플릿에서 Java 코드를 사용하는 것을 피하기 어렵기 때문에 순수 뷰의 개념을 깨고 뷰와 컨트롤러로서 여러 곳에서 코드를 유지하는 것이 어려워집니다.
JSP는 세션을 확립하는 JSP 컨텍스트를 자동으로 만듭니다.피하고 싶을지도 모르지만, 당신의 어플리케이션이 항상 세션을 사용한다면, 그것은 당신에게 문제가 되지 않을 것입니다.
JSP는 컴파일이 필요하며 타겟 시스템에 Java 컴파일러가 없는 경우 다른 시스템을 사용한 후 다시 전개해야 합니다.
최소 JSP 엔진은 바이트 코드와 JSTL의 약 500k이므로 임베디드 시스템에는 적합하지 않을 수 있습니다.
템플릿 엔진은 JSON 페이로드, 웹 페이지, 이메일 본문, CSV 등 동일한 모델의 다른 콘텐츠 유형을 생성할 수 있습니다.
비 Java 프로그래머는 JSP 템플릿을 사용하는 데 어려움을 겪을 수 있습니다. 기술자가 아닌 사람은 일반 템플릿을 수정하는 데 어려움을 겪지 않습니다.
저는 오래 전에 같은 질문을 했고, 다른 솔루션에서 볼 수 있는 모든 단점이 없는 프레임워크(템플릿 엔진 기반)를 작성하는 것으로 끝냈습니다.말할 필요도 없이 그것은 약 10만 바이트 코드입니다.
이게 현명한 답변이라는 건 알지만, 사실은, 현재 프로젝트에서 코드보다 템플릿을 사용하는 것이 더 나을 것 같지 않다면, 아마 현재 프로젝트에는 코드가 없기 때문일 겁니다.
그것의 일부는 규모에 관한 것이다.include가 sitemesh라고 하는 것만큼이나 강력하다고 생각하실 수도 있습니다.적어도 페이지 수가 적으면 (약 100장 정도), 수천 장이면 관리가 불가능해집니다.(따라서 eBay의 경우 필요없고 Salesforce의 경우 필요없을 수 있습니다.)
또한 앞서 언급한 바와 같이 프리마커와 속도는 서블릿에 고유하지 않습니다.메일 템플릿, 오프라인 문서 등 모든 용도로 사용할 수 있습니다.프리마커 또는 속도를 사용하기 위해 Servlet 용기가 필요하지 않습니다.
마지막으로, 당신의 포인트 5는 부분적으로만 해당됩니다.액세스 할 때마다 컴파일 됩니다(아직 컴파일되지 않은 경우).즉, 무언가를 변경할 때마다 JSP를 다시 컴파일할 수 있도록 서블릿 컨테이너 "work" 디렉토리를 삭제해야 합니다.이것은 템플릿 엔진에서는 불필요합니다.
TL;DR Templaing 엔진은 JSP + JSTL의 일부(인식 또는 실제) 단점을 해결하기 위해 작성되었습니다.이러한 기능을 사용할지 여부는 전적으로 요구 사항 및 프로젝트의 규모에 따라 달라집니다.
언급URL : https://stackoverflow.com/questions/3168559/why-would-i-use-a-templating-engine-jsp-include-and-jstl-vs-tiles-freemarker
'programing' 카테고리의 다른 글
| iframe에서 부모 창 함수 호출 (0) | 2022.10.21 |
|---|---|
| Laravel Archent 쿼리에서 테이블에 별칭을 지정하는 방법(또는 Query Builder 사용) (0) | 2022.10.21 |
| 계속하기 전에 하나의 기능이 완료될 때까지 기다리는 올바른 방법입니까? (0) | 2022.10.21 |
| 함수에 전역 변수 사용 (0) | 2022.10.21 |
| Google Invisible reCAPTCHA 배지를 숨기는 방법 (0) | 2022.10.20 |