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 ------------------------------------------------------------------------------ == 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: only a little bit done) + * 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: DONE, but not as described. the tools haven't moved yet, but init() and configure() are supported.) - * 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) + * 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: done) * 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: 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) @@ -48, +48 @@ 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. + * 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. (STATUS: done) 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) + * !ChainedContext users - !ChainedContext extends !ViewToolContext, but what to do about setToolbox()? (STATUS: not quite 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
