JSPが宣伝している利点として、それが現存の.jspページを取り出し、 速度と効率のために、それをコンパイルしてServletにすることがあげあれます。 これが意味することは、最初に.jspページを解析して、結果として 乱雑に、より低レベルになったあとで、javacや、あなたの好きなJava コンパイラ(たとえば: Jikes)によってServletが .class ファイルにコンパイル され、それからServletエンジンにロードされます。 ふぅ、これ全てを説明するだけで頭痛がしてくるけど、あなたはどう?
ポイントは、JSPを使うのは、今や多段階プロセスということです。 JSPの著者は、あなたがそれに気がつきさえしないような方法において、 舞台裏にこのプロセスやり方を隠すうまい仕事をしました。 人は、単に彼らの大好きなエディタで.jspページを編集して、 ページを彼らのブラウザを使用して呼び出すことで、 それからそれを.classファイルに変換するプロセスを開始します。
.jspテンプレートから生成されるものには、いくつかの基本的な問題があります。 まずは、そのクラス名です。 突然生成されるかもしれないので、クラスローダーの問題に対処するために、 エンジンはユニークな名前を生成する必要があります。 したがって、人が.jspページを修正するどの時も、新しいファイルは、 一時的なディレクトリにおいてディスクの上で作成されます。 残念なことに、誰かがそれをクリーンナップしようとするまで、 このディレクトリは結局サイズが増えつづけることになります。 エンジンは、多分、それから、それが間違ったファイルを実際に削除する かもしれないのを除いて、あなたのためにこれをすることが出来る かもしれません。
ポイントは、編集->変換->コンパイル->ロード->実行という全部のプロセスは、 本当に不必要でとくに、悪い設計です。 一方、Velocityは単にテンプレートをロードし、一度だけ、それらを解析します、 それから何度も再利用されるようにメモリで、 テンプレートの抽象的な構文木（AST）表現を格納します。 プロセスは、単に編集->解析->実行です。 結局、利点は非常により速いことと、それもjavacコンパイラと一時的な ディレクトリをうろつくようにする必要がありません。 Velocityで、テンプレートを変更するとき、 現存の蓄積されたテンプレートは単に新たに解析された バージョンと置換されます。
テンプレートのためのVelocityの方法への別の利点は 実際のテンプレート・データがどこにでも格納することができることです。 それには、データベースまたはリモートURIを含まれます。 可変なテンプレート・ローダーを使用することによって、 あなたが欲しいものは何でもすることができるテンプレート・ローダーを作成することが可能です。
Turbineなしでさえ、Velocityはエラーの処置にいくつかの方法を提供します。 StrutsとTurbineのようなフレームワークがすぐ手近にやって来るものは、 エラーを正しく扱う方法を提供しています。 しかし、StrutsがJSP上に基礎をおかれるという事実のために、 それは問題の量がJSPと関連した同じものを受け継ぎます。 次の章は、これに関するより多くの詳細に入ります。
下で示される設計の中の1つの決定的な問題は、 JSPページが例外のものを捕えるだけであるということです。 JSPページが OutOfMemoryError のような別の例外を投げる場合どうだろう？ この問題は、OutOfMemoryError が Throwable (例外でない) に基礎をおかれるということです。 したがって、JSPページだけでこの例外を捕えることは、ずっと難しいです。
NASA(数10億ドル設備を天国に飛ばします)で、 我々の友人によって提供されるこの素晴らしい 例は、 JSPがよりよくエラーの取り扱いを必要とする理由の完全な例です。
絶えず、出力ストリームに書くことはあまり効率的でないので、 バッファリングはまた、別の大きな問題です。
これらは、ページをautoFlushするために出力された12kbをバッファリングするようにJSPに伝える例です。 Struts+JSPは、JSPテンプレートを通してVIEW部分を提供することによってMVCモデルを実装しました。 それらのタグがふさわしいように、あなたはMVCモデルのどんな部分を考えますか？ あなたはそれを推測しました。そして、彼らがいる部分が使われませんでした。
この問題を扱うことへのVelocityの方法は、 開発者を許すことによって翻訳エンジンにストリームをパスすることです。 翻訳の間、投げられる例外があるならば、例外を捕捉して扱うことができます。 緩衝することは、また、パーサーに正しくバッファされたストリームをパスすることによって取り扱われます。 再び、エラーがあるならば、別のストリームは簡単に出力の代用にされることができます。
これは、Tomcat 3.3m2により生成された中間コードの例です。
あなたが判断してください。
[ Saying Hello <- 前 | 次 -> エラーの扱い ]