Ideas For VelocityTools 2.x

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)

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:

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 toolbox.xml for the "simple" example could be simplified further to something like:

{{{<tools>

</tools> }}} (STATUS: done, and now our tools come with a @DefaultKey annotation to make it even simpler)

4. FactorOutBasicVelocityViewStuff: This would create a better basis for bring the Veltag into the project as a sibling of the VelocityViewServlet. (STATUS: 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. (STATUS: done, but needs more testing)

6. Simplify the package structure of VelocityTools. There are a lot of sub-packages that seem redundant or unnecessary. I'd like to shift things about as much as possible to reduce that. (STATUS: done)

Backwards Compatibility For VelocityTools 2.x

1. Basic user interfaces - these are things that people use directly without extending

2. Common extension points - places where people extend the tools, servlets

3. Advanced API users - those that use tool management without using the servlets (e.g. Spring MVC or "standalone" toolbox users)

4. Anyone else that digs further into the tool management API for 1.x - Unless we decide to only deprecate the old tool management infrastructure, these people shouldn't upgrade until they're ready to make a lot of changes. :)

VelocityTools2/Planning (last edited 2009-09-20 22:06:08 by localhost)