Velocity

Velocityについて

コミュニティ

ドキュメント

比較

ツール

日本語訳について

事例研究: XMLC vs. Velocity

少し前に、Jakarta Tomcat メーリングリストで、XMLC と Velocity についての質問が ありました。それに対する、Bojan Smojver <bojan@binarix.com> の興味深い回答を、彼の許可の上でこの Velocity サイトで公開します。


XMLC のチュートリアルでこんな文章を見つけました。

------------------
XMLC は、Hypertext Markup Language(HTML)または eXtensible Markup
Language (XML) で書かれた文書から、忠実にドキュメントを再現する Java
クラスを生成する Java ベースのコンパイラです。出力される Java クラス
は、自動的に動的コンテンツを文書フレームワークに挿入するのに使えます。
したがって、XMLC は Java からダイナミックな HTML や XML文書をつくる
素晴らしい方法です。
------------------

これはJSPに大変似ているように思われますが、このことが Velocity を使う
一番の理由でしょう。

私は Web での作業のために Velocity を使っていますが、Velocity は汎用的
なテンプレートエンジンであり、それ以外の内容を本当に気にしません。
そして、そこが素晴らしいのです。

私は文書を XML から XHTML に変換するのに XSLT (ごめんなさい。Anakia も
検討してみます :-)) を使っていて (Cocoon とは違って、自動的にはやって
くれませんが)、Velocity による変換にはあまりとまどいはありません (XSLT
ではちょっと細工をしないと "&&" (VTL の and) を使えないこと以外は)。
しかし、Ant のすてきな置換テクニックを使った変換には感動しました。

とにかく、XMLC の欠点として第一に挙げられるのは、コード生成での苦労なの
ですが、Velocity では、とてもうまく省いています。

第二の欠点は、ソリューション全体を設計する実際の手順です (下記のページ
で説明されています)。
http://xmlc.enhydra.org/project/aboutProject/index.html

デザイナがページを設計してから、エンジニアがロジックを記述する?
私から見れば全然ダメっぽいです。デザイナが「レゴブロックでいっぱいの箱」
から自分の機能を選べるべきであり、その逆ではないのです。エンジニアが
単純なプロジェクトに関わらなければならない場合、最初のうちは、
エンジニアが何もかもやる羽目になります。そういう場合、JSP や ECS を
使ってしまうのも無理ありません。そうして、また Java まみれになって
しまうのです……。XMLC サイクルは長すぎるだけでまったく意味が
ありません -- デザイナが (意図的であろうがなかろうが) ページの id
をおかしくしたらどうなるでしょうか? エンジニアのコードは全て使えなく
なります。プレゼンテーションと機能が、うまく分離されていますよね(笑)。

これが第二の欠点です。

私の「製造ライン」の例で、Velocity なら上記の問題をうまく解決できる
ことを示したいと思います。私はすべての問合せフォームを処理するいくつか
のクラスを作りました。1つのクラスはフォームのフィールドを処理し、
データベースに格納します。もう1つのクラスはフィールドのデータを拾って、
指定されたメールアドレスにメールします。これらのクラスは Bean になって
いて、ここで使う唯一の Servlet からロードされます (GPL ライセンスです
が、私が作ったものなので、バグがたくさんあるかもしれません)。この
Servlet は全ての Velocity ページを処理するもので、コメントも含めて 331行
あります。上記の Bean にはスコープなど、JSP と同じものが全てあります。

最初に1個だけフォームを作成・デバッグするだけで、あとは、この
「製造ライン」上の Web デザイナ(架空)が、以前に行ったプロジェクトから
既存のVelocityページをコピーし、フィールド (名前、個数……どんなものでも
OKです) を変更して、他のコンテンツにしてくれます。いったん、サイトに
ページを置けばそれでおしまいです。これだけで動作します。作業を行うのに、
エンジニアと話す必要が全然ないのです。XMLC よりも断然いいでしょ?

XMLC、JSP、Servlet が直面している最大の問題は、むしろ哲学的な性質のもの
だと思います。つまり、文書はデータであって、コードではないのです。
そして Velocity はまさにそのように処理するのです。テキストとして
ブラウザに送りたい時に、HTML を Java クラスに変換しなくてもよいのです。

やはり、Velocityは素晴らしいです。

Bojan



このドキュメントは、 熊坂祐二 、 高橋達男 が訳しました。
コメントがある場合は、 report@jajakarta.org までお願いします。
オリジナル英文 Copyright © 1999-2003, The Apache Software Foundation