You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Claude Brisson <cl...@savoirweb.com> on 2002/07/03 13:57:53 UTC

[veltools] Tools initialization

Would it be possible - and how - to pass some initialization parameters to the tools ?

Those parameters would be defined in toolbox.xml, like :

<toolbox>
  <tool>
     <key>toytool</key>
     <class>ToyTool</class>
     <tool-param>
        <param-name>my param</param-name>
        <param-value>my  value</param-value>
     </tool-param>
  </tool>
</toolbox>

We would need something like the ViewTool interface, but the VelocityViewServlet considers implicitely that the init method of this
interface is meant to receive the ViewContext.
Maybe another interface ? Like ParametrizableTool ?

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 ?

Thanks for your help.

CloD



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [veltools] Tools initialization

Posted by Nathan Bubna <na...@esha.com>.
Claude said:
...
> Nathan said :
...
> > 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.

yes, i agree, if you want to distribute the tool, my suggestion is not very
useful.  that's one reason i asked what you needed this for. :-)  but, just
for the record, if we were to make the ToolboxManager easily pluggable in
the VVS, then you could potential just distribute your manager with the
tool.  that's not the best solution, of course, but it's not wholly
unreasonable.

anyhow, given the specifics of your need, Gabe's suggestion certainly seems
best.  one thing you can keep in mind...  i'm not sure what scope you intend
to give this tool(session?),  but you should take care to note that with the
ServletToolboxManager, application scope tools that implement the ViewTool
interface are initialized with the ServletContext directly and session or
request scoped ViewTools are initialized with a ViewContext.   Either way,
that should give access to the resources you need.

Nathan Bubna
nathan@esha.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [veltools] Tools initialization

Posted by Claude Brisson <cl...@savoirweb.com>.
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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [veltools] Tools initialization

Posted by Nathan Bubna <na...@esha.com>.
Claude said:
> Would it be possible - and how - to pass some initialization parameters to
the tools ?

that's an interesting idea.  just out of curiousity, what do you need this
for?

> We would need something like the ViewTool interface, but the
VelocityViewServlet considers implicitely that the init method of this
> interface is meant to receive the ViewContext.

yes, the VelocityViewServlet presently uses the ServletToolboxManager which
initializes tools with the ViewContext.   One option for you if you need
this ability right now, is to extend the VelocityViewServlet to use a
ToolboxManager of your own.   You would need to override VVS's
init(ServletConfig) and createContext(req, res)  methods to do this.

as for your question...  to be honest, i'm guessing that this feature
request is not likely to be needed or used by many people, and it could be
troublesome to implement in a clean, generalized manner.  i can, however,
easily imagine other people having similarly uncommon needs for their tools.
as such, there is something i considered when i rewrote the toolbox support
but didn't get around to implementing.   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?

Nathan Bubna
nathan@esha.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [veltools] Tools initialization

Posted by Gabriel Sidler <si...@teamup.ch>.
Claude,
I don't have the solution to your first question, just a few
thoughts about this.

Claude Brisson wrote:

> Would it be possible - and how - to pass some initialization parameters to the tools ?
> 
> Those parameters would be defined in toolbox.xml, like :
> 
> <toolbox>
>   <tool>
>      <key>toytool</key>
>      <class>ToyTool</class>
>      <tool-param>
>         <param-name>my param</param-name>
>         <param-value>my  value</param-value>
>      </tool-param>
>   </tool>
> </toolbox>


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. 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. Anything that speaks against that approach?

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.

> We would need something like the ViewTool interface, but the  

> VelocityViewServlet considers implicitely that the init method of this
> interface is meant to receive the ViewContext.
> Maybe another interface ? Like ParametrizableTool ?


I see the need for parameterizable tools in some application scenarios.
But this goals is in conflict with the goals to automatically load,
initialize and (in the future) reuse tool instances. I am sure we can
do better than today but I don't yet see the right approach.

> 
> 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. Input to those methods is the context-relative
path to a resource (e.g. file).
See methods getResourceAsStream(), getResource(), getRealPath() of
Interface ServletContext in the Servlet API.

Hope this helps.

Gabe




> 
> Thanks for your help.
> 
> CloD
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> .
> 
> 


-- 
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>