[Velocity Wiki] Update of "VelocityTools2Planning" by NathanBubna

[Apache Wiki <wi...@apache.org>]

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 and change corrections

------------------------------------------------------------------------------
  }}}
  (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: pretty much 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: 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)
+ 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
-   * 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.)
+   * 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 and put deprecated subclasses with init() support in the old tool locations. (STATUS: 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: done)
+   * Custom tools - the trick will be to support the init() method.  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)
@@ -53, +53 @@

  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) though anyone who implemented their own version will find that the tools no longer recognize it.  they need to update to the new ViewContext package name.
    * !ChainedContext users - !ChainedContext extends !ViewToolContext, everything should work superficially as it did before. (STATUS: 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. (STATUS: deprecated, but left otherwise as-is. also, tools still have deprecated but functional init() methods so they work with it)
+   * 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. (STATUS: deprecated, but left otherwise as-is. also, old tools still have deprecated but functional init() methods so they work with 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. (STATUS: same as XML!ToolboxManager)
  
  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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org