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.
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.
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.
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.
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.
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.
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.
IDE Integration
How could Velocity be integrated into standard IDEs like
JBuilder and VisualAge?
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.
