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: fix sub-items of idea 2 ------------------------------------------------------------------------------ == 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). + 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). - 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: + 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). - - 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 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... + * 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: --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
