- updated todo.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/jakarta/velocity/trunk@73285 13f79535-47bb-0310-9956-ffa450edef68
diff --git a/docs/todo.html b/docs/todo.html
index 3e69101..b96ce29 100644
--- a/docs/todo.html
+++ b/docs/todo.html
@@ -141,11 +141,23 @@
object caching/pooling code could be borrowed from Turbine,
JServ, or the Avalon Server Framework.
<P align="justify"></P>
-
+
+ <B>Velocity Profiling</B>
+ <BR>
+ 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 profiling
+ so that anyone who wanted to do some profiling could do
+ so in a consistent manner.
+ <P align="justify"></P>
+
<B>Encoding Caching</B>
<BR>
What would this entail? And how could we implement an
- efficient encoding mechanism.
+ efficient encoding caching mechanism.
<P align="justify"></P>
<B>Plugins</B>
@@ -208,7 +220,21 @@
How could Velocity be integrated into standard IDEs like
JBuilder and VisualAge?
<P align="justify"></P>
+
+ <B>Scripting Language Integration</B>
+ <BR>
+ This is something that has been discussed on the Turbine
+ list. Allowing Context building classes to be written
+ in JPython, Rhino or another scripting language. This would
+ dramatically improve development time and might allow technically
+ proficient web designers who are familiar JavaScript to create
+ an entire servlet solution with Velocity. And as most of these
+ scripting solutions provide a compiler, performance would still
+ remain at an acceptable level.
+ <P align="justify"></P>
+
+
</FONT></TD></TR></TABLE></DIV><BR>
diff --git a/xdocs/todo.xml b/xdocs/todo.xml
index 735847c..0fbc269 100644
--- a/xdocs/todo.xml
+++ b/xdocs/todo.xml
@@ -137,11 +137,23 @@
object caching/pooling code could be borrowed from Turbine,
JServ, or the Avalon Server Framework.
<p/>
-
+
+ <strong>Velocity Profiling</strong>
+ <br/>
+ 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 profiling
+ so that anyone who wanted to do some profiling could do
+ so in a consistent manner.
+ <p/>
+
<strong>Encoding Caching</strong>
<br/>
What would this entail? And how could we implement an
- efficient encoding mechanism.
+ efficient encoding caching mechanism.
<p/>
<strong>Plugins</strong>
@@ -204,7 +216,21 @@
How could Velocity be integrated into standard IDEs like
JBuilder and VisualAge?
<p/>
+
+ <strong>Scripting Language Integration</strong>
+ <br/>
+ This is something that has been discussed on the Turbine
+ list. Allowing Context building classes to be written
+ in JPython, Rhino or another scripting language. This would
+ dramatically improve development time and might allow technically
+ proficient web designers who are familiar JavaScript to create
+ an entire servlet solution with Velocity. And as most of these
+ scripting solutions provide a compiler, performance would still
+ remain at an acceptable level.
+ <p/>
+
+
</s1>
</body>
