Nathan Bubna wrote: > Bill said: > >>I just didn't feel that the "approved" tools (if any) should be >>constructed until they are really used for a specific template and the >>template designer should know them by a "common" name, not a class name. >>"Lazy" construction of the tools just allows for improved performance >>for templates that don't use any/all of them. >> > > "lazy" for the system maybe, but more work for the designer. also, it'll > perform worse or no better for tools that are frequently used. if your > tools are well-designed, the performance hit of pre-populating the context > should be quite negligible. so given that pre-population is better MVC, i > much prefer to avoid encouraging in-template tool loading. i think it > _can_ be a useful development tool, but i don't think it ought to be a > common practice.
Yes, that summarizes well our design intentions with jakarta-velocity-tools. The encouraged approach is the use of the VelocityViewServlet (VVS) to handled the loading of tools automatically: - VVS is a standalone Velocity template renderer. It can be used in a similar fashion as the JSPServlet (in a Struts environment VVS can be easily added next to JSPServlet. An application can then mix JSP templates and Velocity templates at will -> not the encouraged use, but useful for a transition) - Tools to be made available to templates can be configured in a XML-based configuration files. VVS automatically instantiates and initializes tools and adds them into the context. - VVS support three scopes for tools: application, session, request. Tools with a scope of 'application' are instantiated once and reused for all template processing requests, tools with a scope of 'request' are instantiated anew for every request, etc. This ensures efficient handling of tools where possible. - Furthermore, in the design of the tool loading mechanism we have forseen, but not implemeted yet, the possibility to pool and reuse instances of tools, thereby further improving performance. - Conceptually, the handling of view tools in VVS is very similar to the handling of view tools in Turbine 2. At the same time, VVS is completely independent of Turbine. Actually, since Turbine already has good tool support, the construction of VVS was more driven by people using other frameworks. I see the ToolLoader as complementary to the tool loading mechanism of VVS and as the tool of choice for special cases. Its presence recognizes the fact that application scenarios and development environments vary so much, that no one solution suits all needs. - ToolLoader is useful for situations where a tools need special initialization parameters (an automatic tool loading mechanism only works with tools with a known constructor signature). - ToolLoader may be useful for tools that are used very infrequently. - Giving the template designers some control over the view tools to be loaded can actually help in some circumstances to decouple the work on V and C of MVC. - If it is a security concern, simply don't make the ToolLoader available to the template designers (in VVS all it would take is to remove it from the configured list of auto-loaded tools). - Tools can be used without VVS, Turbine or any other framework that has support for auto-loading tools. In such a environment ToolLoader may be the only option to dynamically load tools. A Velocity Standard Tool Library should be useful in as many envrionments are possible. VVS and Turbine are just two of many options. Gabe -- Gabriel Sidler Software Engineer, Eivycom GmbH, Zurich, Switzerland -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
