JSP を悩ませるいくつかの問題と解決策

著者：Eve Cole 更新時間：2009-07-02 17:22:43

今日サーブレットを使用するすべての開発者は、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 コードを使用するのが最善です:

ホームページ

Java コードを避けてタグを使用することもできますが、その場合、次の 6 つの判読不能な文字列が生成されてしまいます:

property="contextPath"/＞/index.html">HomePage＜/a>

テンプレートエンジンを使用すると、Java コードや醜い構文はなくなります。同じ要件の下で WebMacro でどのように記述したかを次に示します。

ホームページ

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("
");
}
%>

おそらく、これらのループを実行するためのユーザー定義タグがいつか登場するでしょう。「もし」についても同様です。 JSP ページは奇妙な Java コードのように見えるかもしれません。そして同時に、ウェブマクロループは美しいです。
#foreach $isp in $isps {
次の名前は $isp.Name です

必要

に応じて、#foreach ディレクティブをカスタムの #foreach-backwards ディレクティブに簡単に置き換えることができます。

jsp を使用する場合、次のようになります: (考えられるタグは次のとおりです)

次の名前は

＜/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 を使用しないソリューションのように見えます。