Thanx for your responses. > > Would it be possible - and how - to pass some initialization parameters to the >tools ?
Nathan said : > that's an interesting idea. just out of curiousity, what do you need this > for? Basically, to read (at the first use) a property file to configure the tool. I'm trying to turn my "velosurf" library into a view tool (it's a lightweight and easy-to-use database abstraction layer for velocity... it's already on sourceforge, but you should wait for the 0.5 release this week, I'll post a mail on the users mailing list). > One option for you if you need > this ability right now, is to extend the VelocityViewServlet to use a > ToolboxManager of your own. hum... not sure - if I want my tool to be re-usable by anyone already using the VVS, my tool should work on its own. > i think perhaps it could be cool to > give developers the option of specifying in their web.xml an alternate > ToolboxManager for VVS to use. This would not save you from writing your > own manager or extending/modifying the ServletToolboxManager, but it would > eliminate the need to extend the VVS. thoughts? Yes but - same remark... if one wants to share tools, one cannot have a specific ToolboxManager. Imho, if we want to have a growing library of usefull tools, the maximum should be done to avoid the need to overload the VVS or the ToolboxManager. Gabriel said : > This could be done, but would mean that the parameter is the same > for the entire lifetime of the web application. This is probably > to limiting for most application cases. Speaking of initialization parameters like config filenames, inet adresses or the like, not sure... > Furthermore, if your > parameter is static over the application's live time, you could > as well use a web application init parameter in web.xml. A view > tool has access to those init parameters through the ViewContext > interface. That may be the right approach, I hadn't seen it. > Anything that speaks against that approach? None, except that a tool parameter would be better located in toolbox.xml than in web.xml (so as to gather everything that concern tools in the same file). For instance, the VVS could merge init-params and tool-params inside the ViewContext it gives to the ViewTools. > Another approach is that you make available an initialization parameter > for a tool in the Velocity Context and let the tool fetch the > initialization parameter from the Velocity Context. This has the > advantage over the approach above that the parameter can vary for > every request or session if needed. And the drawback that you have to overload the VVS or the toolbox before the tool is called, which cannot stand if you want your tool to be generic. > > Another problem : when the parameter is to be a filename > > (an initialization file needed by the tool), how can we ensure that the > > default path is the WEB-INF of the web-app ? > ServletContext provides several methods to access resources within the > context of a web application. Yes, now that I know my tool can access the ServletContext, no more problem with it. Thanx :-) CloD -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
