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: status update ------------------------------------------------------------------------------ == 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, but all needs testing) + 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: * 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) @@ -24, +24 @@ <tool key="map" class="java.util.HashMap"/> </toolbox> <toolbox scope="application"> - <tool key="date" class="org.apache.velocity.tools.generic.DateTool"/> + <tool class="org.apache.velocity.tools.generic.DateTool"/> </toolbox> </tools> }}} - (STATUS: done, but needs testing) + (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 [http://velocity.apache.org/engine/devel/veltag.html Veltag] into the project as a sibling of the VelocityViewServlet. (STATUS: mostly done) + 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: pretty much 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 testing) @@ -39, +39 @@ == Backwards Compatibility For VelocityTools 2.x == 1. Basic user interfaces - these are things that people use directly without extending - * Our tools - the biggest thing here is the tools themselves. we shouldn't make users have to change their templates at all. we might consider finding some way to provide deprecation notices for things we'd like to change, but i don't think there's many places we'll need to do that. in the meantime, the most we may do is move packages, add setup() methods, and put deprecated subclasses with init() and configure() support in the old tool locations. (STATUS: nothing to be done yet) + * Our tools - the biggest thing here is the tools themselves. we shouldn't make users have to change their templates at all. we might consider finding some way to provide deprecation notices for things we'd like to change, but i don't think there's many places we'll need to do that. in the meantime, the most we may do is move packages, add setup() methods, and put deprecated subclasses with init() and configure() support in the old tool locations. (STATUS: only a little bit done) * Custom tools - the trick will be to support the init() and configure() methods. Not sure how this will work, but i'm pretty determined to find a way. (STATUS: not done yet) * Servlets - A lot of people directly use the VVS and VLS. So, while i've moved them to a new package, there are deprecated subclasses at their old location to make this a seamless transition for these folks. (STATUS: done) - * toolbox.xml - We need to create a !FactoryConfiguration that can translate the old xml configuration format to fit the new tool management structure. This should not be too difficult. The trickier part is where we should automatically check for the old format (probably in the deprecated VVS and deprecated VLS, at least). Some thought may need to be put into this. Anyway, the goal is to not force people to update their configurations right away. (STATUS: not done yet) + * toolbox.xml - We need to create a !FactoryConfiguration that can translate the old xml configuration format to fit the new tool management structure. This should not be too difficult. The trickier part is where we should automatically check for the old format (probably in the deprecated VVS and deprecated VLS, at least). Some thought may need to be put into this. Anyway, the goal is to not force people to update their configurations right away. (STATUS: done, though not quite as described above) * Logging stuff - The old !CommonsLog-!LogSystem bridges are deprecated and now extend their successors, the !CommonsLog-!LogChute implementations. I now think that CommonsLogLogChute belongs in Engine, not Tools, but it will have to have a copy here until at least the Engine 1.6 release. Also, !ServletLogger is deprecated and extends its successor, ServletLogChute. For all of these, the transition should be seamless for users also using Engine 1.5. (STATUS: done) * !WebappLoader - This has been deprecated and now extends its successor, !WebappResourceLoader, which is better named and has logging improvements to match those of the other loaders in Engine 1.5. Again, upgrading to 2.x should not break anything for users also using Engine 1.5. (STATUS: done) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
