On the mailing lists, we often get asked to explain the differences between Velocity and WebMacro. Instead of answering the same question over and over, we have started this document to describe some of the differences in our approaches. In reality, both are excellent tools and we feel that it is up to the user base to decide which one they would like to use.

メーリングリストで Velocity と WebMacro の違いを説明して欲しいと言われることがよくあります。 何度も同じ問題に答える代わりに、アプローチの違いの一部を説明するためにこの文書を用意しました。 実はどちらも優れたツールなので、どちらを使うか決めるのは、 ユーザの皆さん次第だと思っています。

The language syntax is very close but not exactly the same. The syntaxes were kept close for a few reasons:

言語構文はかなり似ていますが厳密には同じではありません。 似たような構文にしたのは以下の理由からです。

1) The syntactical approach of $<foo> for references and #<bar> for directives is a good one! It's easy for designers to work with, people understand it, and there was no reason to reinvent the wheel.

1) リファレンスで $<foo>を使い、指示子で #<bar> を使うという、 構文に関するアプローチは優れています。デザイナが使いやすいし、誰でも理解できるので、 新しい構文をわざわざ作り直す理由もありませんでした。

2) Since so many people were using the syntax, why invent another one? Also, it makes the WebMacro to Velocity conversion much easier :) We even have a tool to help with that.

2) 多くの人々がこの構文を使っているのに、なぜ新しい構文を考え出す必要があるでしょう？ それに WebMacro から Velocity への変換が簡単にできます ：） そのためのツールもあります。

Velocity was built new from the ground up. There isn't a snippet of shared code. This was originally done because WebMacro was released under a license (GPL) that is not compatible with the BSD/ASF license and we (the original authors) needed a solution that was not under a GPL license. Since then, WebMacro has been released under a dual GPL/ASF license, however, that was too late, this project was already well underway and we also felt that we have a better technical solution by going with a generated parser instead of a hand coded one.

Velocity は、新たに一から構築されました。[WebMacroと] 共有するコードはありません。 このようにした本来の理由は、WebMacro が BSD/ASF ライセンスと互換性を持たないライセンス (GPL) でリリースされており、我々 (オリジナルの作者) は GPL ライセンスでないソリューションが必要だったからです。 その後、WebMacro は GPL/ASF の両方のライセンスでリリースされましたが手遅れでした。 プロジェクトはすでに軌道に乗っていましたし、 自分でコードを書くよりも [JavaCCで] 生成されたパーサを使う方が、 技術的な解決策としては適切だと思ったからです。

By starting new and fresh, we are less encumbered with some of the baggage that WebMacro must deal with due to backwards compatibility issues. We have fixed a few of the template language inconsistencies that we saw creeping into WebMacro such as the fact that we do not support using {} for code blocks (because we do not need to) and that we use () around all #directives on the right hand side. Examples:

新規に開発したので、 WebMacro が後方互換の問題のせいで扱わざるをえない厄介な問題に、 我々はあまり関わらずに済んでいます。 我々は、WebMacro に紛れ込んだいくつかのテンプレート言語としての不整合を修正しました。 その中には、コードブロックで {} をサポートしないこと (Velocity では不要です）や、 # 指示子 の右側で () を使用することなどがあります。例をあげましょう。

	#set ($bar = "foo") #if ($bar.length() > 0) stuff here #end

Architecturally, the biggest difference until recently was the parser. The Velocity parser is written using a tool called javacc, a very popular Java-based parser generator. It was originally developed for Sun by Metamata and is now maintained and managed by Metamata as well : www.metamata.com.

アーキテクチャ的には、最近まで一番違っていたのはパーサでした。 Velocity パーサは、JavaCC (非常に人気がある Java ベースのパーサ/ジェネレータ) というツールを使用して書かれます。 それは、元々は Metamata が Sun のために開発したもので、 保守や管理も Metamata が行っています。
[訳注：上記のサイトは現在存在しません。保守・管理に関しては、現在では java.net 内のコミュニティが行っています。]

The WebMacro parser was written by hand until recently and was the cause of much pain when using WebMacro (due to many bugs in it) - their new parser, for their 0.95 release is also written using javacc and promises to be better (however, support for a lot of the baggage still exists).

WebMacro パーサは最近まで手で書かれていたため、(それによる多くのバグのせいで) WebMacro を使う際には多くの苦労がありました。0.95 のリリースの新しいパーサは JavaCC を使って書かれているので、きっと改善されたことでしょう (とはいえ、多くの過去の遺物へのサポートは残っています) 。

Velocity is very simple in its architecture, as it is meant to be nothing more than a template engine. The idea is to do one thing only and do it well. Much in the spirit of the Unix philosophy - have a good set of simple tools, and create bigger things using them. This has enabled Velocity to be used as the basis for several different tools, such as Anakia and Texen.

Velocityのアーキテクチャは極めて単純で、テンプレートエンジン以外の何物でもありません。 その考え方は、ひとつのことだけをちゃんと行うということです。 そうした考え方は Unix の思想に多く見られます -- つまり単純なツールを適切に集めて、 それを元により大きいものを作るということです。 これが、Velocity が Anakia や Texen など様々なツールのベースとして使われるようになった理由です。

Velocity is recognized that it isn't going to try to be a 'development framework' - there are plenty around, such as Turbine.

Velocity を「開発フレームワーク」にするつもりはありません -- すでにそういったものはたくさんあります。例えば Turbine がそうです。

Therefore, all facilities like 'context tool' and 'resource brokers' are purposely left out of Velocity, acknowledging that not only will frameworks do it, they will do it better anyway. Further, by leaving out of the Velocity core much that should be done at the application / user / framework level, the Velocity core remains smaller and therefore, in our opinion, more maintainable and extensible.

したがって、「コンテキストツール」や「リソースブローカ」といった 機能は全て Velocity からわざと外しています。 そういったことはフレームワークが行うでしょうし、 その方がとにかく適切だと認識しているからです。 さらに、アプリケーション/ユーザ/フレームワークのレベルで行うべきことの多くを Velocity コアから外すことによって、 Velocity コアを小さいままにしておけますし、 それによって、(あくまで我々の意見ですが)メンテナンスや拡張がしやすくなります。

Internally, Velocity is pretty straightforward. There are no threads created or managed for you. Templates are parsed and caches, kept in their internal form of an 'Abstract Syntax Tree', a tree structure that is then rapidly walked when your template is merged. Each node corresponds to on of the syntactical elements in your template.

内部的には Velocity はかなり単純です。ユーザ向けのスレッドは生成も管理も行いません。 テンプレートは解析され、内部では「抽象構文木」形式となるキャッシュとして保持されます。 この形式は木構造となっており、テンプレートがマージされた時に高速に処理できます。 個々のノードはテンプレート内の構文要素のどれか一つに対応しています。

Internally within WebMacro, many of the methods and classes are marked as private and/or final in order to achieve better speed. However, this has prevented people from easily extending or overriding some of the core funtionality and re-using some of the code. We would rather sacrifice a few ms in favor of allowing more people to use our software easily.

WebMacro の内部では、処理を高速にするためにメソッドやクラスの多くは private や final、あるいはその両方になっています。しかし、その結果、 ユーザがコア機能を容易に拡張/オーバーライドしたり、 コードの一部を再利用するのが難しくなりました。 我々は、ソフトウェアが使いやすくなるのなら、 数ミリ秒の処理速度なら犠牲にしても構わないと思っています。

The biggest feature difference between the two are the 'Velocimacros'. Velocimacros can be thought of as snippets of re-usable data that can contain anything. They are parsed just like the data in a #parse() statement would be and you can pass in variables that can optionally have scope only within the Velocimacro.

機能における両者のもっとも大きな違いは「Velocimacro」です。 Velocimacro は、何でも入れられる再利用可能データの断片群と考えてよいでしょう。 #parse() ステートメント内のデータと同じように、Velocimacroは解析され、 そしてVelocimacro 内であれば任意のスコープで変数を扱うことができます。

Velocimacro's are also helping keep the core #directive set small and clean. In other words, WebMacro is adding #directives to the core at an increasing rate and we are not. We would rather support optional downloads for that "extra" funtionality that can be shared.

また、Velocimacro のおかげで、コアの # 指示子は少数で整理された状態を維持できます。 言い換えれば、WebMacro は、コアに # 指示子をどんどん追加していますが、 我々はそうではありません。そうした共有可能な「特別な」機能については、 オプションのダウンロードとしてサポートしたいと思います。

We hope this helps. The best way to understand Velocity is to use it, and of course nothing beats looking at the source code.

この文書がお役に立てばと思います。とはいえ、Velocity を理解する一番の方法は、 使ってみることです。もちろん、ソースコードを見るのに勝るものはありません。