web-dev-qa-db-ja.com

テンプレートエンジンを使用する理由jsp includeおよびjstl vsタイル、freemarker、velocity、sitemesh

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

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

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

TilesおよびSitemeshはグループ化できます。 FreemarkerおよびVelocityを使用できます。各グループ内でどれを使用するかは、この議論の問題ではなく、それについての十分な質問と議論があります。

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

私の質問は-これらのフレームワークは何を与えてくれるのですか？<@ include file="..">およびJSTL。主なポイント（記事の一部）：

  1. ヘッダーやフッターなどのページの一部を含める-間に違いはありません：

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

    そして

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

  2. ヘッダーのパラメーターの定義-タイトル、メタタグなど。これは、特にSEOの観点から非常に重要です。テンプレートオプションを使用すると、各ページで定義するプレースホルダーを簡単に定義できます。しかし、jspでは[〜＃〜] jstl [〜＃〜]で、<c:set>（インクルードページ内）および<c:out>（含まれているページ内）

  3. レイアウトの再編成-パンくずをメニューの上に移動する場合、またはログインボックスを別のサイドパネルの上に移動する場合。 （jspを使用した）ページの包含がうまく編成されていない場合、そのような場合にはすべてのページを変更する必要があるかもしれません。ただし、レイアウトが過度に複雑でなく、ヘッダー/フッターに共通のものを配置する場合、心配する必要はありません。

  4. 共通コンポーネントと特定のコンテンツとの結合-これに関する問題は見つかりません。フラグメントを再利用する場合は、ヘッダー/フッターを含まないページに移動し、必要な場所に含めます。

  5. 効率-<%@ include file="file.jsp" %>は、一度コンパイルされるため、他の何よりも効率的です。他のすべてのオプションは、何度も解析/実行されます。

  6. 複雑さ-すべての非jspソリューションには、追加のxmlファイル、追加のインクルード、プリプロセッサ構成などが必要です。これは学習曲線であり、より多くの可能性をもたらします障害点。また、サポートと変更がより面倒になります-何が起こっているのかを理解するために、多くのファイル/構成を確認する必要があります。

  7. プレースホルダー-速度/フリーマーカーはJSTL以上のものを提供しますか？ JSTLでは、プレースホルダーを配置し、モデル（コントローラーによって要求またはセッションスコープに配置）を使用して、これらのプレースホルダーを埋めます。

したがって、プレーンなJSPの代わりに/に加えて、上記のフレームワークのいずれかを使用する必要があることを確信してください。

javajspvelocitytilesfreemarker
93
Bozho

Velocityのいくつかの引数（Freemarkerは使用していません）：

  • メールの送信など、Webコンテキスト外でテンプレートを再利用する可能性
  • Velocityのテンプレート言語の構文はfarJSP ELまたはタグライブラリよりも簡単です
  • ビューロジックと他の種類のロジックとの厳密な分離-スクリプトレットタグの使用やテンプレートでの厄介なことを行うためのドロップダウンオプションはありません。

プレースホルダー-速度/フリーメーカーはJSTL以上のものを提供しますか？ JSTLでは、プレースホルダーを配置し、モデル（コントローラーによって要求またはセッションスコープに配置）を使用して、これらのプレースホルダーを埋めます。

はい、 references は実際にはVTLのコアです：

<b>Hello $username!</b>

または

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

効率 - <%@ include file="file.jsp" %>は、一度コンパイルされるため、他の何よりも効率的です。他のすべてのオプションは、何度も解析/実行されます。

私はこの点に同意するか、または理解するかわからない。 Velocityにはテンプレートをキャッシュするオプションがあります。つまり、テンプレートから解析される抽象構文ツリーは、毎回ディスクから読み込まれるのではなくキャッシュされます。いずれにせよ（そして、私はこれについて堅実な数字を持っていない）、Velocityはいつも私にとってfastを感じていた。

レイアウトの再編成-パンくずをメニューの上に移動する場合、またはログインボックスを別のサイドパネルの上に移動する場合。 （jspを使用した）ページの包含がうまく編成されていない場合、そのような場合にはすべてのページを変更する必要があるかもしれません。ただし、レイアウトが過度に複雑でなく、ヘッダー/フッターに共通のものを配置する場合、心配する必要はありません。

違いは、JSPアプローチでは、同じヘッダー/フッターを使用するすべてのJSPファイルでこのレイアウトを再編成しませんか？ TilesとSiteMeshを使用すると、ベースレイアウトページ（JSP、Velocityテンプレートなど、両方とも中心となるJSPフレームワーク）を指定できます。ここで、必要なものを指定し、メインコンテンツの「コンテンツ」フラグメント/テンプレートに委任できます。 。つまり、ヘッダーを移動するファイルは1つだけです。

17
matt b

jsp:includeとTiles/Sitemesh/etcは、開発者が常に直面するsimplicity and powerの間の選択です。もちろん、ファイルの数が少ない場合や、レイアウトが頻繁に変更されると思わない場合は、jstlとjsp:include。

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

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

11
mooreds

他のテクノロジーを使用するよう説得するつもりはありません。すべての人にとって、JSPがうまく機能するのであれば、誰もがJSPに固執するべきだと知っています。

私は主にSpring MVCで作業しており、SiteMeshと組み合わせたJSP 2 +が完璧に一致しています。

SiteMesh 2/3

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

JSP 2+

JSPを使用するとテンプレートのJavaコードを回避するのが難しくなると主張する人々は偽りです。これを行うべきではありません。このバージョンではそうする必要はありません。これは、以前のバージョンと比較して大きな利点です。

[〜＃〜] jstl [〜＃〜]タグを使用すると、コードは依然としてHTMLのように見えるため、扱いにくくなります。 Springは、非常に強力なtaglibを介してJSPの多くのサポートをパックします。

Taglibも簡単に拡張できるため、独自の環境を簡単にカスタマイズできます。

4
Bart

JSPを使用するのとは反対に、faceletの最良の引数（リストにはありませんが、ただ言及します）は、コンパイルがJSPコンパイラーに委任されるのではなく、インタープリターと統合されることです。これは、JSF 1.1で私が抱えていた最も厄介なことの1つ-ランタイムエンジンが変更を検出するために変更を保存するときに周囲のJSFタグのid属性を変更する必要があったことを意味します-エディタ内、ブラウザ内の再読み込み、およびはるかに優れたエラーメッセージ。

2
Thorbjørn Ravn Andersen

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

2
Ibrahim

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

JSPテンプレートでJavaコードを使用しないようにするのは難しいため、純粋なビューの概念を破り、結果としてビューとコントローラーとして複数の場所でコードを維持するのが困難になります。

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

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

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

テンプレートエンジンは、同じモデルの異なるコンテンツタイプ、たとえばJSONペイロード、ウェブページ、電子メール本文、CSVなどを生成できます。

Non Javaプログラマーは、非技術者が通常のテンプレートを変更するのに苦労したことがないのに、JSPテンプレートで作業するのが難しい場合があります。

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

1
Singagirl

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

その一部はスケールに関するものです。インクルードは、たとえばsitemeshと同じくらい強力で、少なくとも少数のページ（おそらく約100）については確かに真実であると思うかもしれませんが、数千がある場合、管理不能になり始めます。 （つまり、eBayの場合は必要ありません。Salesforceの場合はおそらく必要です）

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

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

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

0
Mikkel Løkke