指令のインタフェース
現在、指令のための非常に乏しいインタフェースがありますが、
JavaCC についての若干の知識は必要です。
指令のインタフェースは、中心的な Velocity 開発者の外側で使うつもりはありません
(public APIにすべきではない) がしかし、おそらく、
指令を作成する人を JavaCC から保護することは意味があります。
キャッシュ
コンテキストでのオブジェクトがおよそどのようにキャッシュされるべきか、
キャッシングがどのように指定されるべきか、
誰がキャッシングを制御するべきかは、議論をするために良いです：
また、デザイナー、テンプレートに何が書くべきか、
開発者、コンテキスト置くオブジェクトの有効期限、
サードパーティのもの、それらのコンテンツマネージャーなど。
例えば、本のトップ10のリストからなる配列がコンテキストで置かれるとしましょう。
このトップ10のリストは、24時間の期間の間有効かもしれません：
どのように、それは指定されるはずですか？
コンテンツマネージャーが後で、このリストが
１週間有効であることになると決めると言ったとしましょう。
彼らはデザイナーに述べます、そしてその人は変化の変更点でテンプレート、
あるいは、我々はいくらかの種類の Web アプリケーションを用いて、
変更点にコンテンツマネージャーを許す仕組みに
その特定のコンテキスト・オブジェクトのためのデフォルトの終了時間を
提供することができましたか？
基礎は、もしこの議論が使い方と方針のうちの1つでなければ、
Velocity で柔軟なキャッシュしているシステムのために置かせられます。
UML概要
Velocity を記述する包括的な UML 図の集合を含むられれば素晴らしいです。
これは、新しい開発者が速く予備知識を得ることができます。
Velocity プロファイリング
誰かが標準のプロファイラーのうちの1つの扱いがうまいならば、
ボトルネックを捜し始めることは素晴らしいでしょう。
重大な最適化は、始まりませんでした。
しかし、JUnit テスト組合せの存在による接合で、
最適化変更点は、自信をもって作られることができました。
そう共通のプロファイラーのために準備の構成を持つことは、
素晴らしいですそのいくつかをしたかった誰輪郭を描きます
一貫した方法の中のそうすることができました。
構文ダンパー
現在、最初の構文ダンパーが Velocity コード・ベースにあります、
そして、それは改善することができました。
このツールはデバッグする際に非常に役に立ちます、そして、それはまた、
指令をつくるために良いです。
それは、基本的に全ての AST ノード・タイプのために使われる単純なダンプ・メソッドを持ちます。
生産される構造が少しより明白であるように、ダンプ・メソッドを特定のASTノード・タイプに合うように変えることは良いです。
構文チェッカー
標準の構文チェッカー（全ての構文エラーを見つけて、わかりやすい
若干のフォーマットでデザイナーにそれらを報告する何か）を持つことは、良いです。
このツールは、DreamWeaver のようないろいろなデザイナー・ツールにフックすることができました。
コンパイラ
テンプレート・コンパイラを持つことは、素晴らしいです。
利用されることができた DynamicJava パッケージの中に、クラス・ファイルを作成する非常にきれいで単純な方法を提供して、また、存在するコードを生成している数バイトのコードでそこである JavaClass と呼ばれている素晴らしいユーティリティがあります。
IDE 統合
どうしたら、Velocity は JBuilder と VisualAge のような標準の IDE に組み込むことがでるでしょうか？
スクリプト言語統合
これは、Turbine リストで検討されたものです。
JPython、Rhino、または他のスクリプトを書いている言語で書かれるコンテキスト構築しているクラスを許すことは、劇的に開発時間を改善して、Velocity で全 servlet ソリューションを作成するよく知られている JavaScript である技術的に熟達した Web デザイナーを許すかもしれません。
大部分のこれらのスクリプトを書いているソリューションがコンパイラを提供するので、パフォーマンスは受け入れられるレベルでまだ残ります。
