This is an informal document describing what needs to be done in the Velocity code base and the Velocity documentation. If you need more detailed help, or have specific questions, please send mail to the mailing list (velocity-dev@jakarta.apache.org). The Todo list that follows is roughly in order of importance.
この文書は、Velocity コードベースと Velocity ドキュメントで行うべきことを記載した非公式の文書です。 詳細なヘルプが必要か、個別に質問があるならば、 メーリングリスト（velocity-dev@jakarta.apache.org）に、メールを送ってください。 以下の To Do リストは、重要度順に並んでいます。
Directive Interface
Right now there is a very thin interface for directives, but
some knowledge of JavaCC is required. The directive
interface is not intended to be used outside core Velocity
developers (it is not intended to be a public API), but it
probably makes sense to shield directive creators from JavaCC.
指示子のインタフェース
今のところ、指示子についてはインタフェースが少しだけありますが、
javaCC を知っている必要があります。
指示子のインタフェースは、中心的な Velocity 開発者以外が使うためのものではありません
(パブリックな API にしようとは思っていないということです) が、指示子の作成者が JavaCC
を意識しなくてすむことは、おそらく意味があるでしょう。
Caching
It would be good to have a discussion about how objects
in the context should be cached, how the caching
should be specified, and who should control the
caching: the designer, by specifying something in the template;
the developer,
by placing expiry times on objects placed in the context;
or a third party, such as a content manager. For example,
say an array consisting of a top 10 list of books is
placed in the context. This top 10 list might be valid
for a 24 hour period: how should that be specified? Say
a content manager later decides this list will be valid
for a week. Do they tell the designer, who in turn changes
the template, or could we provide a mechanism that would
allow a content manager to change the default expiry time
for that particular context object with the aid of a webapp
of some sort? The groundwork has be laid for a flexible
caching system in Velocity, but this discussion would be
one of usage and policy.
キャッシュ
コンテキスト内のオブジェクトをどのようにキャッシュするべきかとか、
キャッシュをどのように指定すべきかとか、
キャッシュ方法を制御するのはデザイナ (テンプレートで何かを指定する) なのか、
開発者 (コンテキストのオブジェクトに有効期限を設定する) なのか、
それとも第三者 (コンテンツマネージャとか) なのか、
といったことを議論すべきでしょう。
例えば、本のトップ10のリストの入った配列をコンテキストに設定するとしましょう。
このトップ10のリストを24時間有効にしないといけない場合、
どのように指定すればいいのでしょうか？
また、その後コンテンツマネージャがこのリストを１週間有効にすると決めたとします。
その場合、デザイナに言ってテンプレートを変更してもらうのでしょうか？ それとも、
Webアプリか何かを使って、コンテンツマネージャが特定のコンテキストのデフォルトの
有効期限を変えられるような仕組を Velocity で提供するのでしょうか？
柔軟なキャッシュシステムの基盤はVelocityの中に存在していますが、
この議論はその使い方やポリシーに関するものになるでしょう。
UML Overview
It would great to include a set of comprehensive
UML diagrams that describe Velocity. This would
allow new developers to get up to speed quickly.
UML による概要
Velocity を記述する包括的な一連の UML 図を用意できると素晴らしいと思います。
これがあれば、新規開発者が予備知識を迅速に得られるでしょう。
Velocity Profiling
If someone is handy with one of the standard profilers,
it would be great to start hunting for bottlenecks. No
serious optimization has been started. But in conjuction
with the presence of a JUnit test suite, optimization
changes could be made with confidence. It would be nice
to have a configuration of a setup for a common profiler
so that anyone who wanted to do some profiling could do
so in a consistent manner.
Velocity プロファイリング
標準のプロファイラのうちの1つに詳しい人がいたら、
ボトルネックの探索に着手してもよかったと思います。
最適化については、今のところちゃんと行っていませんが、
JUnit テストスイートが登場したので、これと組み合わせれば、
最適化のための変更を自信を持って行えるでしょう。
プロファイリングを一貫した方法で行えるように、
共通のプロファイラを設定できるといいなと思います。
Syntax Dumper
Right now there is a primitive syntax dumper in the Velocity
code base, and it could be improved. This tool is very helpful
in debugging, and it is also good for creating directives.
It basically has a simple dump method that is used for all
the AST node types. It would be good to tailor dump methods
for particular AST node types so that the structure produced
is a little clearer.
構文ダンパ
現在のところ、 Velocity コードベースには初歩的な構文ダンパしかなく、
改善の余地があります。このツールはデバッグの際に非常に役に立ちますし、
指示子を作成するのにも適しています。生成される構造がもう少しきれいになるように、
個々の AST ノードタイプに応じてダンプメソッドをカスタマイズできるといいと思います。
Syntax Checker
It would be good to have a standard syntax checker, something
that would find all syntax errors and report them to the
designer in some intelligible format. This tool could be
hooked into various designer tools like DreamWeaver.
構文チェッカ
全ての構文エラーを見つけて、何かわかりやすいフォーマットでデザイナに報告できる、
標準の構文チェッカがあるといいと思います。
このツールは DreamWeaver など様々なデザイナツールに組み込むことができるでしょう。
Compiler
It would be great to have a template compiler. There is a great
utility called JavaClass that provides a very clean and simple way
to create class files, and there is also some byte code generating
code present in the DynamicJava package that could be utilized.
コンパイラ
テンプレートコンパイラがあるとすごくいいなと思います。
とても美しくかつシンプルな方法でクラスファイルを作成する JavaClass
という素晴らしいユーティリティがありますし、
DynamicJava パッケージにはバイトコードを生成するコードがあり、
これを活用することも可能でしょう。
IDE Integration
How could Velocity be integrated into standard IDEs like
JBuilder and VisualAge?
IDE 統合
JBuilder や VisualAge といった標準の IDE に Velocity
をどうやって組み込めばいいでしょうか？
Scripting Language Integration
This is something that has been discussed on the Turbine
list. Allowing Context building classes to be written
in JPython, Rhino or other scripting languages would
dramatically improve development time and might allow technically
proficient web designers who are familiar JavaScript to create
an entire servlet solution with Velocity. As most of these
scripting solutions provide a compiler, performance would still
remain at an acceptable level.
スクリプト言語統合
これは、Turbine メーリングリストで検討されています。コンテキストを構築するクラスを、
JPython や Rhino などのスクリプト言語で書ければ、開発期間を劇的に短くでき、
JavaScript を使い慣れていて技術に詳しいWebデザイナなら、
Velocity を使って Servlet ベースのシステムを構築できるかも知れません。
こうしたスクリプトによるソリューションではたいていコンパイラも提供されているので、
性能についても受容できるレベルになるでしょう。