[Velocity Wiki] Update of "VelocityTools2Planning" by NathanBubna

[Apache Wiki <wi...@apache.org>]

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:
create page to track and organize ideas for tools 2.x

New page:
== Ideas For VelocityTools 2.x ==

1. TransparentOnDemandToolsLoading: Instead of a standard HashMap, the idea here is to have a Toolbox, perhaps inheriting 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).

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 two 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).
 - 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
 - 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...

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>
    <toolbox scope="request" xhtml="true">
        <tool key="toytool" class="ToyTool" valid-path="index.vm"/>
    </toolbox>

    <toolbox scope="session" create-session="true">
        <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>

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.

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org