95

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

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

  • タイル
  • サイトメッシュ
  • フリーマーカー
  • 速度
  • <jsp:include>
  • <%@ include file="..">

タイルとサイトメッシュはグループ化できます。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 の代わりに、またはプレーンな JSP に加えて、上記のフレームワークのいずれかを使用する必要があることを確信してください。

4

7 に答える 7

17

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 ファイルでこのレイアウトを再編成しないことです。タイルと SiteMesh を使用すると、ベース レイアウト ページ (JSP、Velocity テンプレートなど - どちらも本質的には JSP フレームワーク) を指定して、必要なものを指定してから、メイン コンテンツの「コンテンツ」フラグメント/テンプレートに委譲することができます。 . これは、ヘッダーを移動するファイルが 1 つだけであることを意味します。

于 2010-07-02T20:18:41.477 に答える
12

Tiles/Sitemesh/etcjsp:includeとの間の選択は、開発者が常に直面するシンプルさとパワーの間の選択です。確かに、少数のファイルしかない場合、またはレイアウトが頻繁に変更されるとは思わない場合は、 and を使用してください。jstljsp:include

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

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

于 2011-05-12T19:26:44.320 に答える
5

他の技術を使うように説得するつもりはありません。私が知っている限りでは、それがうまくいくのであれば、誰もが JSP に固執するべきです。

私は主に Spring MVC を使用しており、SiteMesh と組み合わせた JSP 2+は完璧にマッチしています。

サイトメッシュ 2/3

ビューに適用されるデコレーターを提供します。ほとんどの場合、他のテンプレート エンジンで継承が機能します。このような機能は、今日ではこれなしでは機能しません。

JSP 2+

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

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

taglibs は拡張も簡単なので、独自の環境を簡単にカスタマイズできます。

于 2014-04-08T22:12:20.320 に答える
2

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

于 2011-08-16T12:34:32.347 に答える
2

JSP の使用に反対する facelets (あなたのリストにはありませんが、私はそれについて言及します) の最良の議論の 1 つは、コンパイルが JSP コンパイラに委譲されるのではなく、インタープリターと統合されることです。これは、JSF 1.1 で最も面倒だったことの 1 つ (実行時エンジンが変更を検出するために変更を保存するときに、周囲の JSF タグの id 属性を変更しなければならないこと) がなくなり、保存を提供することを意味します。エディター内、ブラウザー内のリロード サイクル バック、およびはるかに優れたエラー メッセージ。

于 2010-07-02T20:05:01.753 に答える
1

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

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

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

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

最小の JSP エンジンは約 500k のバイトコードと JSTL で構成されているため、組み込みシステムには適していません。

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

非技術者が通常のテンプレートを変更するのに苦労したことがないのに対し、非 Java プログラマーは JSP テンプレートを扱うのに苦労するかもしれません。

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

于 2014-02-13T08:36:26.230 に答える
0

これは賢明な回答だと思いますが、実際には、現在のプロジェクトでコードよりもテンプレートを使用する利点が見られない場合、それはおそらく現在のプロジェクトにテンプレートがないためです。 .

その一部はスケールに関するものです。インクルードは、たとえばサイトメッシュと同じくらい強力だと思うかもしれません。少なくとも少数のページ (おそらく 100 程度) については確かにそうですが、数千のページがあると、管理が難しくなり始めます。(したがって、eBay の場合は必要ありませんが、Salesforce の場合はおそらく必要です)

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

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

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

于 2014-02-13T08:58:36.403 に答える