JSPでの利点として、既存の .jsp ページを速度と効率上の理由からコンパイルして Servletにできることが喧伝されています。それがどういうことかと言えば、まず .jspページを解析し、このページの最後に出てくるようなごちゃごちゃしたコードにした上で、 javacや、あなたの好きな Java コンパイラ (例えば Jikes) で、この Servletが .class ファイルにコンパイルされ、それから Servlet エンジンにロードされます。ふぅ・・・これを説明するだけで頭痛がしてきましたが、いかがですか?

要するに、今のところ、JSP を使うには多段階のプロセスが必要だということです。 JSP の作者は、ユーザがプロセスがあることさえ気がつかないぐらい、こうしたプロセスのあれこれを裏に隠すのに成功しています。ユーザは好きなエディタで .jsp ページを編集し、ブラウザを使って、ページを .class ファイルに変換するプロセスを開始する URI 経由で、ページを呼び出すだけです。

生成された .jsp テンプレートにはいくつかの根本的な問題があります。まずは、そのクラス名です。つまり、クラスローダーの問題に対処するために、エンジンはユニークな名前を生成する必要があるということです。したがって、誰かが .jsp ページを修正するたびに、新しいファイルがディスクのテンポラリディレクトリに作成されます。残念なことに、誰かがそれを掃除しない限り、このディレクトリのサイズは増えつづけることになります。ひょっとしたらエンジンが代わりに削除してくれるかもしれませんが、そうすると、間違って、削除してはならないファイルを削除してしまうかもしれません。

要するに、編集->変換->コンパイル->ロード->実行という全体のプロセスは、実際不必要ですし、何より設計として良くないということです。それに対して、Velocity は単にテンプレートをロードし、一度だけ解析し、何度でも再利用できるように、テンプレートを抽象構文木（AST）表現でメモリに格納します。プロセスは、単に編集->解析->実行と、単純です。利点としては、Velocity テンプレートを使うと非常に処理が速くなり、 javacコンパイラとテンポラリディレクトリの間を行ったり来たりする必要がなくなることです。 Velocityでは、テンプレートを変更する際も、既存の蓄積されたテンプレートが、新たに解析されたバージョンと置き換わるだけです。

テンプレートを使う Velocity のアプローチのもう一つの利点は実際のテンプレートデータをどこにでも格納できることです。格納場所としてはデータベースやリモートURIも含まれます。設定可能なテンプレートローダーを使用することにより、何でもできるテンプレートローダーを作成することが可能です。

Turbine がなくても、Velocity でエラー処理を行う方法がいくつかあります。 Struts や Turbine といったフレームワークの便利なところは、エラー処理を適切に行えることです。しかし、Struts は JSP に基礎を置いているという事実のために、 JSP に関する問題を JSP と同じだけ引き継いでいます。次の章では、これに関してさらに詳細に説明します。

後述される設計の問題の中でも決定的なものとして、 JSP ページは Exception しか捕えられないことです。もし、JSP ページが OutOfMemoryError といった他の例外を投げたらどうなるでしょうか? ここでの問題は、OutOfMemoryError が (Exception ではなく) Throwable ベースにしているということです。したがって、JSP ページだけでこの例外を捕えるのは、ずっと難しいです。将来のバージョンの JSP 仕様・実装では、これに関しては改善される予定です。

このすてきな例は、 NASA (数10億ドルの機器を天国に飛ばしています) の友人が提供してくれたもので、 JSP でのエラー処理の改善がなぜ必要か、ということに関する完璧な例です。

バッファリングはもう一つの大きな問題です。なぜなら、絶えず出力ストリームに書くのはあまり効率的でないからです。

<%@ page autoFlush="true" %> ]]>

この例では、出力を 12kb だけバッファリングし、ページを autoFlush するように JSP に命令します。Struts と JSP の組み合わせでは、JSP テンプレートで View の部分を提供することによって、MVC (Model-View-Controller) モデルを実装しています。上記のタグは MVC モデルのどこに属していると思いますか? ご想像の通り、ここ [View] はこれらのタグを使うべきところではありません。

この問題に対する Velocity でのアプローチは、開発者がテンプレート処理エンジンにストリームを渡すというものです。テンプレート処理の途中で例外が投げられたら、例外を捕えて処理できます。また、バッファリングについては、パーサに適切にバッファされたストリームを渡すことで対応できます。この場合も、エラーが発生したら、その出力の代わりに別のストリームを使うこともできます。

これは、Tomcat 3.3 m2 で生成された中間コードの例です。

\r\nHello\r\n\r\n

\r\n"); if (request.getParameter("name") == null) out.write("\r\n Hello World\r\n"); else out.write("\r\n Hello, "); request.getParameter("name"); out.write("\r\n

\r\n\r\n"); } catch (Exception ex) { if (out != null && out.getBufferSize() != 0) out.clearBuffer(); if (pageContext != null) pageContext.handlePageException(ex); } finally { if (out instanceof org.apache.jasper.runtime.JspWriterImpl) { ((org.apache.jasper.runtime.JspWriterImpl)out).flushBuffer(); } if (_jspxFactory != null) _jspxFactory.releasePageContext(pageContext); } } } ]]>

[どちらを選ぶかは] あなたが判断してください。

[ Saying Hello <- 前 | 次 -> エラーの扱い ]