なぜテンプレートエンジンを使用するのですか？jsp includeおよびjstl vs tiles、freemarker、velocity、sitemesh

私は自分のビューを整理する方法を選択しようとしています（spring-mvcを使用しますが、それほど重要ではありません）

私が見る限り、6つのオプションがあります（ただし、相互に排他的ではありません）。

• タイル
• Sitemesh
• フリーマーカー
• 速度
• <jsp:include>
• <%@ include file="..">

タイルとSitemeshはグループ化できます。FreemarkerとVelocityも同様です。各グループ内でどれを使用するかは、この議論の問題ではありません。それについて十分な質問と議論があります。

これは興味深い記事ですが、タイルを使用するように私を説得することはできません。

私の質問は-JSTLでは適切に実行できないこれらのフレームワーク は何を提供するのですか？<@ include file="..">主なポイント（一部は記事から引用）：

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を使用していません）：

• メールの送信など、Webコンテキスト外でテンプレートを再利用する可能性
• 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ファイルでこのレイアウトを再編成しないのですか？TilesとSiteMeshを使用すると、基本レイアウトページ（JSP、Velocityテンプレートなど、どちらも中心的なJSPフレームワーク）を指定できます。ここで、好きなものを指定して、メインコンテンツの「コンテンツ」フラグメント/テンプレートに委任できます。 。つまり、ヘッダーを移動するファイルは1つだけです。

選択肢間jsp:includeおよびタイル/ Sitemeshの/ etc間の選択であるシンプルさとパワー、開発者がすべての時間に直面していること。確かに、ファイル数が少ない場合や、レイアウトが頻繁に変更されることを期待しない場合は、とを使用jstlしてくださいjsp:include。

しかし、アプリケーションには段階的に成長する方法があり、「新しい開発を停止してタイル（または他のソリューション）を改良して、将来の問題をより簡単に修正できるようにする」ことを正当化するのは難しい場合があります。最初は複雑なソリューションです。

アプリケーションが常にシンプルであるか、アプリケーションの複雑さのベンチマークを設定してから、より複雑なソリューションの1つを統合できる場合は、タイルなどを使用しないことをお勧めします。それ以外の場合は、最初から使用します。

他のテクノロジーを使用するように説得するつもりはありません。すべての人にとって、JSPが機能する場合は、JSPだけに固執する必要があることを知っています。

私は主にSpring MVCを使用しており、SiteMeshと組み合わせたJSP 2+が完全に一致していると思います。

SiteMesh 2/3

他のテンプレートエンジンでの継承動作のように、ビューに適用されるデコレータを提供します。このような機能は、今日なくして機能することは考えられません。

JSP 2+

JSPがテンプレート内のJavaコードを回避するのを困難にするだろうと主張する人々は、偽物です。あなたはそれをすべきではありません、そしてこのバージョンではそうする必要はありません。バージョン2は、ELを使用したメソッドの呼び出しをサポートしています。これは、以前のバージョンと比較して大きな利点です。

JSTLは、タグ、それはあまり厄介ですので、あなたのコードはまだHTMLのようになります。Springは非常に強力なtaglibsを介してJSPの多くのサポートをパックします。

taglibは拡張も簡単なので、独自の環境をカスタマイズするのも簡単です。

JSPの使用に反対する（リストにはありませんが、ここでは触れません）ファセットの最良の引数の1つは、コンパイルがJSPコンパイラーに委任されるのではなく、インタープリターに統合されることです。これは、JSF 1.1で最も煩わしいことの1つ-ランタイムエンジンが変更を検出するために変更を保存するときに、周囲のJSFタグのid属性を変更する必要があったことを解消し、エディタ内、ブラウザ内のリロードサイクルが大幅に改善され、エラーメッセージが大幅に改善されました。

優れたビュー技術は、ほとんどの最も厄介なif / switch / conditionalステートメントを排除しますが、単純なincludeは排除しません。「複雑な」ビューテクノロジーを使用すると、「シンプルな」アプリケーションになります。

特定のアプリケーションに関する情報を提供していません。たとえば、いくつかの理由でJSPを使用していません。

JSPテンプレートでJavaコードを使用しないようにするのは難しいので、純粋なビューの概念を壊すことになります。その結果、ビューやコントローラとしていくつかの場所でコードを維持することが困難になります。

JSPは、セッションを確立するJSPコンテキストを自動的に作成します。私はそれを避けたいかもしれませんが、アプリケーションが常にセッションを使用している場合、それはあなたにとって問題にはなりません

JSPはコンパイルを必要とし、ターゲットシステムにJavaコンパイラがない場合は、他のシステムを使用して再デプロイするために、微調整が必​​要になります。

最小のJSPエンジンは約500kのバイトコードとJSTLなので、組み込みシステムには適さない可能性があります

テンプレートエンジンは、同じモデルのさまざまなコンテンツタイプ（JSONペイロード、Webページ、電子メール本文、CSVなど）を生成できます。

通常のテンプレートを変更するのに技術者以外の人が問題を経験したことがないのに、Java以外のプログラマーは、JSPテンプレートの操作が困難な場合があります。

私はずっと前に同じ質問をしていましたが、他のソリューションで見たすべての不利な点のないフレームワーク（確かにテンプレートエンジンベース）を書くことで終わりました。言うまでもなく、それは約100kのバイトコードです。

私はこれが賢いお尻の答えとして外れることを理解していますが、それが真実であることは、現在のプロジェクトでコードにテンプレートを使用することに利点がない場合、それはおそらく現在のプロジェクトに1つがないためです。

その一部は規模に関するものです。includeはsitemeshと言った場合と同じくらいパワフルだと思うかもしれませんが、少なくとも少数のページ（おそらく100程度だと思います）の場合は確かにそうですが、数千ある場合は管理できなくなります。（したがって、eBayの場合は不要です。Salesforceの場合はおそらく必要です）

また、前述したように、フリーマーカーと速度はサーブレット固有ではありません。何にでも使用できます（メールテンプレート、オフラインドキュメントなど）。freemarkerまたはvelocityを使用するためにサーブレットコンテナは必要ありません。

最後に、あなたのポイント5は部分的にしか真実ではありません。まだアクセスされていない場合は、アクセスされるたびにコンパイルされます。つまり、何かを変更した場合は、サーブレットコンテナの「work」ディレクトリを削除して、JSPを再コンパイルする必要があることを忘れないでください。これは、テンプレートエンジンでは不要です。

TL; DR Templaingエンジンは、JSP + JSTLの（認識された、または実際の）いくつかの欠点に対処するために作成されました。それらを使用する必要があるかどうかは、要件とプロジェクトの規模に完全に依存します。