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: add some notes/plans for how & where to keep backward compatibility with 1.x ------------------------------------------------------------------------------ 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) + 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: partly done) + + == 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) + * 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) + * 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) + + 2. Common extension points - places where people extend the tools, servlets + * Servlet subclasses - we need to support this as much as possible. (STATUS: partly done) + * Tool subclasses that change init() or configure() - if we meet all the goals in #1 above, then this should happen automatically for the most part. we just need to leave our init() and configure() methods in place, so that calls to super.init() or super.configure() do not fail. + + 3. Advanced API users - those that use tool management without using the servlets (e.g. Spring MVC or "standalone" toolbox users) + * !ViewContext users - can use deprecated one at old location for now (STATUS: done) + * !ChainedContext users - !ChainedContext can extend !ViewToolContext, but what to do about setToolbox()? (STATUS: not done) + * XML!ToolboxManager users - may be possible to hack up a version that reads old toolbox.xml format, and returns a Map of initialized tools for getToolbox(initData), but that initData part is tricky. partial support is probably the best we can do here, unless we leave all the old code intact and just deprecate it. + * !ServletToolboxManager users - similar situation to that of XML!ToolboxManager, but worse. again, probably a choice between partial integration with new infrastructure or else leaving both infrastructures side-by-side with one deprecated. + + 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. :) + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
