Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Velocity Wiki" for 
change notification.

The following page has been changed by NathanBubna:
http://wiki.apache.org/velocity/VelocityTools2Planning

The comment on the change is:
update to reflect progress so far

------------------------------------------------------------------------------
  == Ideas For VelocityTools 2.x ==
  
- 1. TransparentOnDemandToolsLoading: Instead of a standard HashMap, the idea 
here is to have a Toolbox, perhaps inheriting from !HashMap, which will 
instantiate a tool from its tool-info only when the generic getter is called. 
This should be a quite interesting performance gain in some situations. We 
maybe need some attribute to have tools instantiated at toolbox initialization 
('instantiate-on-load' ?).  The Toolboxes may then pool or at least hold on to 
instantiated tools for subsequent requests from the template or from other 
parts of the webapp (see idea 2 below).
+ 1. TransparentOnDemandToolsLoading: Instead of a standard HashMap, the idea 
here is to have a Toolbox, which will instantiate a tool from its tool-info 
only when the generic getter is called. This should be a quite interesting 
performance gain in some situations.  If it seems useful, we could add a 
special attribute to force a tool to be instantiated at toolbox initialization 
('instantiate-on-load' ?).  The Toolboxes may then pool or at least hold on to 
instantiated tools for subsequent requests from the template or from other 
parts of the webapp (see idea 2 below).  (STATUS: done except for the 
'instantiate-on-load' attribute, but all needs testing)
  
  2. EasierToolAccessOutsideTemplates: Other objects in my webapp are often 
jealous of the VelocityViewServlet. They also would like to use some of the 
tools. Session scoped tools can be reached via the session, but it's not the 
case for application or request scoped tools. To achieve this, there would be a 
few things to do:
-  * create a separate Toolbox for each scope and store it in the attributes of 
the corresponding servlet API object (request->!ServletRequest, 
session->!HttpSession, application->!ServletContext).
+  * create a separate Toolbox for each scope and store it in the attributes of 
the corresponding servlet API object (request->!ServletRequest, 
session->!HttpSession, application->!ServletContext). (STATUS: done)
-  * the ChainedContext would know to search the attributes for these Toolboxes 
and pass requests for the tools on to them.  (NOTE: depending on the 
implementation of idea 1 (above) it may be advantageous to have the 
ChainedContext hold on to requested tools as templates often use them multiple 
times.
+  * the !ViewToolContext (successor of !ChainedContext) will search the 
attributes for these Toolboxes and pass requests for the tools on to them. 
(STATUS: done)
-  * We could create a simple utility to help other classes retrieve tools, so 
they needn't all duplicate the code for finding the toolbox in the attributes 
and then requesting the tool from the toolbox...
+  * We could create a simple utility to help other classes retrieve tools, so 
they needn't all duplicate the code for finding the toolbox in the attributes 
and then requesting the tool from the toolbox...  (STATUS: not done)
  
  3. SimplifiedToolboxXML: In line with the ideas above, we could cut out some 
repetition in toolbox.xml by better organizing it and using XML more 
appropriately.  For instance, the 
[http://svn.apache.org/viewvc/velocity/tools/trunk/examples/simple/WEB-INF/toolbox.xml?revision=487337&view=markup
 toolbox.xml for the "simple" example] could be simplified further to something 
like:
  
  {{{<tools>
+     <data type="number" key="version" value="1.1"/>
+     <data type="boolean" key="isSimple" value="true"/>
+     <data key="foo" value="this is foo."/>
+     <data key="bar">this is bar.</data>
      <toolbox scope="request" xhtml="true">
-         <tool key="toytool" class="ToyTool" valid-path="index.vm"/>
+         <tool key="toytool" class="ToyTool" restrictTo="index.vm"/>
      </toolbox>
-     <toolbox scope="session" create-session="true">
+     <toolbox scope="session">
+         <property name="create-session" value="true" type="boolean"/>
          <tool key="map" class="java.util.HashMap"/>
      </toolbox>
      <toolbox scope="application">
          <tool key="date" class="org.apache.velocity.tools.generic.DateTool"/>
-         <data type="number" key="version" value="1.1"/>
-         <data type="boolean" key="isSimple" value="true"/>
-         <data key="foo" value="this is foo."/>
-         <data key="bar">this is bar.</data>
      </toolbox>
  </tools>
  }}}
+ (STATUS: done, but needs testing)
  
- 4. FactorOutBasicVelocityViewStuff:  This would create a better basis for 
bring the [http://velocity.apache.org/engine/devel/veltag.html Veltag] into the 
project as a sibling of the VelocityViewServlet.
+ 4. FactorOutBasicVelocityViewStuff:  This would create a better basis for 
bring the [http://velocity.apache.org/engine/devel/veltag.html Veltag] into the 
project as a sibling of the VelocityViewServlet. (STATUS: mostly done)
  
- 5. SupportAlternateToolboxConfiguration: Not everyone likes XML.  I'd like us 
to make Toolbox management pluggable with provided support for configuration 
via properties file as well as XML, and i want it to be easier to configure and 
manage in Java as well.
+ 5. SupportAlternateToolboxConfiguration: Not everyone likes XML.  I'd like us 
to make Toolbox management pluggable with provided support for configuration 
via properties file as well as XML, and i want it to be easier to configure and 
manage in Java as well. (STATUS: done, but needs testing)
  

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to