Velocity とは、汎用テンプレートエンジンです。
色々な用途に使えます。
注目してほしいのが、JSPの置き換えです。
今まで、JavaでWebと言ったら何の迷いも無くJSP(もしくはJSF)を選択していたあなた。
Velocityという選択肢はいかがですか。
Velocityには、こんなメリットがあります。
JSPでは、拡張タグを使い過ぎると極端に速度が低下します。
拡張タグを使えないとなると、残された選択肢は一つしかありません。
そう、JSP内にバリバリJavaコードを書くのです。
しかし、スピードアップの為に保守性を犠牲にするなんて考え、
今の時代には古いと思いませんか?
Velocityを使えば、綺麗なファイル内容を保ったまま
スピードアップを実現できます。
実例ですが、Limywebの日記サイトでは 以前JSPを使って(表示だけで)300ms掛かっていたページが Velocityを使うことによって1ms以下で表示できるようになりました。
JSPはインラインJavaコードと拡張タグにより
極限まで拡張性を高められます。
しかし、それによってファイル内容は非常に複雑化してしまい
J2EEの目的である「ビュー(表示)とコントロール(実装)の分離」は
到底出来なくなってしまいます。
Velocityは非常なシンプルな構文を持っています。
Javaコードを内部に埋め込むことは一切出来ません。
しかし、決してこれをデメリットと取らないで下さい。
ビュー(表示)の中にコントロール(実装)を埋め込むのは
本来間違っているのです。そうしなくても、あなたの望む処理はきっと実現できます。
JSPは、Tomcatなどのアプリケーションサーバ内からしか使えません。
これはデバッグやテスト時には非常に不便であり、好ましいことではありません。
Velocityは、いつどこからでも使えます。
このような依存性の低さは、Velocityの大きな魅力です。
JSPのデバッグに悩まされた事のある人は多いはずです。
それは仕方の無い事だと言う人もいるかもしれません。
しかし、よく考えてみて下さい。
ビュー(表示)に何故デバッグが必要なのですか?
コントロール(実装)をビューから分離するためにServletを使っているのに。
JSPはこんなに複雑な構成をしています。
JSPテンプレート(JSPファイル) --+ + Webアプリケーションコンテナ --+ JSPコンパイラ --+--> JSPクラスファイル --+ サーブレットリクエスト --+ セッション --+--> 出力内容 データベース --+ 拡張タグ --+ etc... --+
これは大抵の場合、サーブレットよりも複雑です。
コントロールよりもビューの方が複雑なんて、おかしな話だと思いませんか?
Velocityは、非常にシンプルな構成をしています。
必要なのは、元となるテンプレートリソース(vmファイル)と
それに与える入力値(のツリー)だけです。
入力値(ツリー構造) --------+ +--> 出力内容 テンプレート(VMファイル) --+
実際、これだけで充分なのです。
よりシンプルに。それが、全ての作業をスムーズに進めるための秘訣です。