This saves the template author from having to remember what keys were used where and makes it easy to drop a new template i. View into an app without having to modify the controller which would typically involve creating a new action class.
The default VelocityTools 2 configuration does not include any "gross MVC offenders", as such things would be hard to generalize usefully. The default configuration primarily includes tools for manipulating values made available in the template's context by a controller and a few for accessing static resources.
However, it is likely that you will want to add your own data and tools to your VelocityTools 2 configuration or at least want to change the default settings of the standard tools.
To that end, configuration of your applications "toolbox es " can be done via XML, Java or properties. Different configurations can also be easily combined together. There a few basic concepts to the configuration that it is useful to know. First, what you are creating a configuration for is a ToolboxFactory. If this causes any errors for you, please report them to user velocity. Once you have your application compiling and running with Tools 2, your next step is to begin updating or replacing deprecations.
Many of these should show up with deprecation warnings during compiling or deprecation notices in your logs. Read through these carefully to be aware of all that needs updating. Below is a list of instructions for handling many of these:. The extra packages had proved superfluous and problematic.
All VelocityView classes are now in the org. Those that remain in the subpackages are merely deprecated shells that extend the classes in the new location. Also, some classes have had their class names adjusted to be more consistent with existing conventions. NOTE: If you are still using the old toolbox.
First, update your configuration , otherwise your tools may not work as expected. Also, this is not a complete list. Please take note of all deprecation warnings and notices when compiling and running your app.
Along with the class renamings above have come many deprecations that have no one-to-one replacement class. The vast majority of these have to do with tool management, as XMLToolboxManager and all of its subclasses and support classes could not simply be evolved to achieve the key goals for Tools 2. A few other classes are simply no longer necessary in any form. Here is an overview of all these deprecations-without-direct-replacements:. If you used it or ServletToolboxManager you were probably a more advanced user or a framework developer working to integrate VelocityTools support.
If so, you should go read this document. If you used ServletToolboxManager directly, you should learn about all of the above classes except perhaps ToolManager and the following ones as well:. This allows the VelocityView which is a rather heavy object to be shared across multiple servlets, tags, and filters in the same application. Of course, if you do not wish to share your VelocityEngine configuration template cache, global macros or Toolbox configuration s , then you should explicitly avoid using these methods and construct and manage your own VelocityView instance.
This is unfinished. You can help fix that! See this email thread for more on this, including code samples. The so-called "standalone" methods of tool use developed from a desire to use tools directly , particularly the GenericTools which had no servlet dependencies.
0コメント