今日サーブレットを使用するすべての開発者は、Sun Microsystems が発明した Web テクノロジである JSP を知っており、サーブレット テクノロジの普及と構築に多大な労力を費やしました。 JSP は HTML コードをサーブレットから切り離すため、Web アプリケーションの開発とページのメンテナンスが高速化されます。実際、Sun が発行した公式の「アプリケーション開発モデル」文書では、さらに詳しく説明されています。「JSP テクノロジは標準とみなされるべきであり、サーブレットはほとんどの場合、補足とみなされます。」(セクション 1.9、1999/12/15)。意見を聞くバージョン）。
この記事の目的は、JSP を別のサーブレット ベースのテクノロジであるテンプレート エンジンと比較することによって、このステートメントの妥当性を評価することです。
サーブレットを直接使用する場合の問題
当初、サーブレットが発明され、全世界がその優位性を認識しました。サーブレットに基づく動的 Web ページは迅速に実行でき、複数のサーバー間で簡単に転送でき、バックエンド データベースと完全に統合できます。サーブレットは、Web サーバーの推奨プラットフォームとして広く受け入れられています。
しかし、通常は単純な方法で実装される HTML コードでは、プログラマが HTML の各行に対して out.println() を呼び出す必要があり、これが実際のサーブレット アプリケーションでは深刻な問題となっています。 HTML コンテンツはコードを通じて実装する必要がありますが、大規模な HTML ページの場合、これは退屈で時間のかかる作業です。さらに、Web コンテンツの責任者は、すべての更新を行うために開発者を雇わなければなりませんでした。このため、人々はより良い解決策を探しています。
JSP登場！
JSP0.90が登場しました。この手法では、Java コードを HTML ファイルに埋め込むと、サーバーがページ用のサーブレットを自動的に作成します。 JSP はサーブレットを作成する簡単な方法であると考えられています。すべての HTML は out.println() を呼び出すことなく直接取得でき、ページ コンテンツの責任者は Java コードを壊す危険を冒さずに HTML を直接変更できます。
しかし、ページ アーティストと開発者が同じファイルで作業するのは理想的ではなく、HTML に Java を埋め込むことは、HTML を Java に埋め込むのと同じくらい厄介であることが判明しました。ごちゃごちゃしたコードを読むのはまだ難しいです。
その結果、人々は jsp の使用に成熟し、JavaBeans をより多く使用するようになりました。 Bean には、jsp に必要なビジネス ロジック コードが含まれています。 JSP のコードの大部分は、取り出して Bean に組み込むことができ、Bean を呼び出すための非常に少量のマークアップのみが残ります。
最近では、このような JSP ページは実際にはビューに似ていると考えられるようになりました。これらは、クライアント要求の結果を表示するために使用されるコンポーネントになります。そこで人々は、なぜビューにリクエストを直接送信しないのかと考えるでしょう。 ターゲット ビューがリクエストに適していない場合はどうなりますか? 結局のところ、多くのリクエストには結果ビューを取得するための複数の可能性があります。たとえば、同じリクエストによって、成功したページ、データベース例外エラー レポート、パラメータが欠落しているエラー レポートが生成される場合があります。同じリクエストで、クライアントのロケールに応じて英語のページまたはスペイン語のページが生成される場合があります。なぜクライアントはリクエストをビューに直接送信しなければならないのでしょうか? なぜクライアントはリクエストを汎用サーバー コンポーネントに送信し、JSP ビューが何を返すかをサーバーに決定させるべきではないのでしょうか?
これにより、多くの人が「」として知られるようになりました。モデル 2」デザイン。これは、JSP 0.92 で定義されたモデル ビュー コントローラー ベースのモデルです。この設計では、リクエストはサーブレット コントローラーに送信され、サーブレット コントローラーがビジネス ロジックを実行し、表示用に同様のデータ「モデル」を生成します。このデータは表示のために JSP の「ビュー」に内部的に送信され、JSP ページが通常の埋め込み JavaBean のように見えるようになります。 制御を担当するサーブレットの内部ロジックに基づいて、適切な JSP ページを選択して表示できます。このようにして、JSP ファイルは美しいテンプレート ビューになります。これはもう 1 つの開発であり、今日に至るまで他の開発者によって賞賛されています。
テンプレート エンジン
を使用して汎用 JSP を置き換えると、その後の設計が簡素化され、構文が単純になり、エラー メッセージが読みやすくなります。 、ツールがさらに使いやすくなります。 いくつかの会社がそのようなエンジンを作成していますが、最も有名なのはおそらく WebMacro ( http://webmacro.org 、Semiotek 社) であり、そのエンジンは無料です。
開発者は、JSP を置き換えるテンプレート エンジンを選択すると、このような技術的な利点が得られることを理解する必要があります。これは、JSP の欠点の一部でもあります
問題 #1: Java コードがテンプレート化されすぎている
設計が悪いと考えられていますが、JSP は依然として Java を追加しようとします。 Web ページにコードを追加します。これはかつて Java が行っていたものに似ており、C++ を簡素化したもので、テンプレート エンジンも jsp の下位レベルのソース コードを削除して簡素化しました。テンプレート エンジンはより優れた設計を実装します。
質問 #2: Java コードが必要である
JSP ページに Java コードを記述する必要があります。たとえば、ページが現在の Web アプリケーションのルート コンテキストを決定し、そのホームページにつながるとします。
JSP で次の Java コードを使用するのが最善です:
<a href="<%= request.getContextPath() %>/index.html">ホームページ</a>
Java コードを避けて <jsp:getProperty> タグを使用することもできますが、その場合、次の 6 つの判読不能な文字列が生成されてしまいます:
<a href="<jsp:getProperty name="request"
property="contextPath"/＞/index.html">HomePage＜/a>
テンプレート エンジンを使用すると、Java コードや醜い構文はなくなります。同じ要件の下で WebMacro でどのように記述したかを次に示します。
<a href="$ Request.ContextPath ;/index.html">ホーム ページ</a>
WebMacro では、ContextPath は Perl に似た構文を使用して $Request 変数の属性として使用されます。他のテンプレート エンジンは他の構文タイプを使用します。
別の例を見て、高度な「ビュー」がユーザーのデフォルトのカラー構成を記録するために Cookie を設定する必要があるとします。このタスクはサーブレット コントローラーではなくビューによって完了する可能性が高いと思われます。 JSP には次のような Java コードが必要です:
<% Cookie c = new Cookie("colorscheme", "blue"); response.addCookie(c); %>
WebMacro には Java コードがありません:
#set $Cookie.colorscheme =
元の Cookie のカラー構成を取得する場合は、最後のイオンとして
「青」を
使用します。JSP の場合、そのような低レベルのことを getCookies() で直接実行するのはばかげていて困難になるため、対応するツール クラスを考えることができます。 JSP の場合:
<% String Colorscheme = ServletUtils.getCookie(request, "colorscheme"); %>
WebMacro にはツール クラスは必要ありません (通常は $Cookie.colorscheme.Value)。 JSP を作成するグラフィック アーティストにとって、どの構文が習得しやすいでしょうか?
JSP 1.1 では、任意の HTML のようなタグが JSP ページのバックグラウンドで Java コードを実行できるようにするカスタム タグが導入されました。これにはある程度の価値がありますが、これは広く知られている、無料で利用できる、フル機能の標準化されたタグ ライブラリがある場合に限られます。現在、そのようなタグ ライブラリはありません。
問題 #3: 単純なタスクは依然として面倒である
ヘッダーやフッターを組み込むなどの単純なタスクでも、JSP では依然として非常に困難です。 すべてのページに含める「ヘッダー」と「フッター」テンプレートがあり、各テンプレートのコンテンツに現在のページ タイトルが含まれている必要があるとします。
JSP での最良の方法は次のとおりです。
＜% 文字列タイトル = "ページタイトル" %>
＜%@ include file="/header.jsp" %＞
...ページのコンテンツ...
＜%@ include file="/footer.jsp" %＞
ページ設計者は、最初の行のセミコロンを省略せず、タイトルを文字列として定義することを忘れないでください。さらに、/header.jsp および /footer.jsp はルート ディレクトリに存在し、完全にアクセス可能なファイルである必要があります。
WebMacro にヘッダーとフッターを含めるのは比較的簡単です:
#set $title = "ページ タイトル"
#parse "ヘッダー.wm"
ここのコンテンツ
#parse "footer.wm"
デザイナーが覚えておくべきセミコロンやタイトルの定義はなく、.wm ファイルはカスタマイズ可能な検索パスに配置できます。
問題 #4: 非常に太いループ
JSP でのループは困難です。ここでは、JSP を使用して各 ISP オブジェクトの名前を繰り返し出力します。
<%
列挙体 e = list.elements();
while (e.hasMoreElements()) {
out.print("次の名前は ");
out.println(((ISP)e.nextElement()).getName());
out.print("<br>");
}
%>
おそらく、これらのループを実行するためのユーザー定義タグがいつか登場するでしょう。 「もし」についても同様です。 JSP ページは奇妙な Java コードのように見えるかもしれません。そして同時に、ウェブマクロ ループは美しいです。
#foreach $isp in $isps {
次の名前は $isp.Name です <br>
必要
に応じて、#foreach ディレクティブをカスタムの #foreach-backwards ディレクティブに簡単に置き換えることができます。
jsp を使用する場合、次のようになります: (考えられる <foreach> タグは次のとおりです)
<foreach item="isp" list="isps">
次の名前は <jsp:getProperty name="isp" property="name"/> <br>
＜/foreach＞
デザイナーは当然前者を選択します。
問題 #5: 役に立たないエラー メッセージ
JSP には、驚くべきエラー メッセージが表示されることがよくあります。これは、ページが最初にサーブレットに変換されてからコンパイルされるためです。優れた JSP ツールを使用すると、エラーの場所を見つける可能性が比較的高くなりますが、最良のツールであっても、すべてのエラー メッセージを簡単に読み取れるようにすることはできません。変換プロセスにより、一部のエラーはツールで識別できない場合があります。
たとえば、JSP ページですべてのページに共通のタイトルを作成する必要があるとします。次のコードには何も問題はありません。
<% static String title = "Global title" %>
しかし、Tomcat は次のエラー メッセージを表示します。
work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: ステートメントが必要です。
静的整数カウント = 0;
^
この情報は、上記のスクリプトが _jspService() メソッドに配置されており、静的変数をメソッドに配置することは許可されていないと考えられます。構文は <%! %> である必要があります。ページ設計者がこれらのエラー メッセージを読むのは困難です。最高のプラットフォームであっても、この点では不十分です。すべての Java コードをページの外に移動しても問題は解決しません。また、次の式はどこが間違っているのでしょうか？
<% カウント %>
Tomcat は次のように与えます:
work/8080/_0002ftest_0002ejsptest_jsp_0.java:56: クラス数が見つかりません
型宣言。
カウント
^
work/8080/_0002ftest_0002ejsptest_jsp_0.java:59: 宣言が無効です。
out.write("rn");
^
つまり、単なるマークの欠落です。 <%= count %> である必要があります。
テンプレート エンジンはコードに大幅に変換することなくテンプレート ファイルから直接生成できるため、適切なエラー レポートを行うのが非常に簡単です。 類推すると、C 言語コマンドが Unix シェルのコマンド ラインに入力されるとき、コマンドを実行するための C プログラムをシェルに生成させる必要はなく、シェルが単にコマンドを解釈して実行するだけで十分です。エラーがあれば直接報告してください。
問題 #6: コンパイラが必要
JSP では、Web サーバーにコンパイラが配置されている必要があります。 Sun が javac コンパイラを含む tools.jar ライブラリの放棄を拒否したため、これが問題になりました。 Web サーバーには、IBM の Jikes などのサードパーティ コンパイラを含めることができます。しかし、そのようなコンパイラは (C++ で書かれた) すべてのプラットフォームでスムーズに動作するわけではなく、純粋な Java Web サーバーの構築には役に立ちません。 JSP には、完璧ではありませんが、役立つプリコンパイル オプションがあります。
問題 #7: スペースの無駄
JSP は余分なメモリとハードディスクのスペースを消費します。サーバー上の 30K の JSP ファイルごとに、30K を超える対応するクラス ファイルを生成する必要があります。ハードドライブの容量を効果的に 2 倍にします。 <%@ include> を介していつでも JSP ファイルに大きなデータ ファイルを簡単にインクルードできることを考慮すると、この懸念は非常に実用的な意味があります。同時に、各 JSP のクラス ファイル データをサーバーのメモリにロードする必要があります。これは、サーバーのメモリに JSP ドキュメント ツリー全体を永久に保存する必要があることを意味します。いくつかの JVM には、クラス ファイル データをメモリから移動する機能がありますが、通常、プログラマは再宣言のルールを制御できず、大規模なサイトでは再宣言があまり効率的ではない可能性があります。テンプレート エンジンの場合、2 番目のファイルが生成されないため、スペースが節約されます。テンプレート エンジンは、プログラマがテンプレートをメモリにキャッシュする方法を完全に制御することもできます。
テンプレート エンジンの使用にはいくつかの問題もあります。
テンプレートの問題 #1: 厳密に定義されていない
テンプレート エンジンがどのように機能するかが厳密に定義されていません。ただし、JSP と比較すると、これは実際にはそれほど重要ではありません。JSP とは異なり、テンプレート エンジンには Web サーバーに対する特別な要件はありません。サーブレットをサポートするサーバーであれば、テンプレート エンジンをサポートできます (Apache/JServ などの API 2.0 サーバーも含まれます)。 JSP を完全にはサポートしていません)! 最適なテンプレート エンジンの設計をめぐる健全な競争が、特にオープン ソースの推進によって (アイデアが互いに推進し合うことを可能にして) めくるめく革新を引き起こした可能性があるとしたら、今日の WebMacro は Perl のようになるでしょう。厳密に定義されているわけではありませんが、オープンソース組織の推進がその標準です。
テンプレートの問題 #2: 認識されない
テンプレート エンジンは広く知られていません。 JSP は巨大な商業市場を占め、人々の心に深く根付いています。 g テンプレート エンジンの使用は、理解されていない代替テクノロジに過ぎません。
テンプレートの問題 #3: 導入されていない
テンプレート エンジンはまだ高度に構成されていません。テンプレート エンジンと JSP の間のパフォーマンス テストや比較は行われません。理論的には、適切にデプロイされたテンプレート エンジンの実装は、適切にデプロイされた JSP と一致するはずですが、サードパーティが JSP を大幅に推進していることを考慮すると、適切にデプロイされているのは JSP だけです。
JSP の役割
もちろん、JSP は将来的にその役割を担うことになるでしょう。 JSP と ASP の類似点は名前からもわかりますが、違いは 1 文字だけです。したがって、ASP を使用している人が Java に切り替える場合、これを促進する上で、ASP との対応関係を維持する役割が重要になります。
ただし、ここで重要なのは、新しい環境に移行する労働者にとって何がメリットとなるかということと、それが実際にその環境を利用するのが最善の方法であるかどうかの間には大きな違いがあるということです。
JSP は、最も重要な Java テクノロジの 1 つになりつつあることをますます示しており、人々が ASP の世界から離れることを可能にします。したがって、Sun はこの強力なビジネス ケースをサポートし、Java 関連テクノロジのサポーターもより強力なサポートを提供することになります。
ただし、これは Java プラットフォームにとって最適なソリューションではありません。これにより、Java ソリューションは Java を使用しないソリューションのように見えます。