> > and internally, the ServletToolboxManager would maintain a hashtable from > the toolbox.xml real path to its specific instances (this > > appears quite reasonable to have one manager per toolbox, no ?) > > yeah, this is pretty good. how/where are you planning to do the loading of > the toolbox.xml file?
the getManager can take care of it and call the load(InputStream) method if a new instance has to be built > the ToolboxManager was not meant to be tied to the servlet API. Ah, right ! > just require that > anyone plugging their own manager in make it extend ServletToolboxManager. > (personally, i prefer the latter.) me too, that's the good solution > > By the way, shouldn't the VVS properties be prefixed by > "org.apache.velocity.tools" ? > > eh, that doesn't really follow the pattern of most velocity.props keys. it of the ones that are inside the velocity.properties, that's true... but not of the only one which is in the web.xml : org.apache.velocity.properties = '/WEB-INF/velocity.properties' So ? One prefix pattern for init-params and another for props files ? ;-) > would be more inline to prefix VVS properties with something like > "tools.view.servlet". so for the manager, i think > "tools.view.servlet.toolbox.manager.class" would be a good key. As you wish, but we are speaking of a servlet init/context param, aren't we ? Just as the "toolbox" param, which is not currently prefixed... CloD ----- Original Message ----- From: "Nathan Bubna" <[EMAIL PROTECTED]> To: "Velocity Developers List" <[EMAIL PROTECTED]>; "Claude Brisson" <[EMAIL PROTECTED]> Sent: vendredi 10 janvier 2003 20:41 Subject: Re: [VELTOOLS] Why isn't ServletToolboxManager a singleton class ? > Claude said: > > Tying to keep it simple, I was thinking of one ServletToolboxManager per > toolbox.xml > > > > this solves the runtimeSingleton mode problem as long as the multiple > toolboxes case. > > > > thus I would propose a method like : > > > > static ServletToolboxManager.getManager( ServletContext context, String > toolboxFile ) > > > > and internally, the ServletToolboxManager would maintain a hashtable from > the toolbox.xml real path to its specific instances (this > > appears quite reasonable to have one manager per toolbox, no ?) > > yeah, this is pretty good. how/where are you planning to do the loading of > the toolbox.xml file? > > > About the pluggable behaviour : very easy to do from a "manager" init > property that contains a class name, but then the proposed > > getManager method has to appear in the ToolboxManager interface. > > i agree, it shouldn't be difficult to do, but i'm against adding this > getManager(ServletContext, String) method to the ToolboxManager interface. > the ToolboxManager was not meant to be tied to the servlet API. the current > design was the result of a number of long discussions concerning the > possibility/hope that some or all of this tool management library could at > some point be used with non-servlet technologies (just as velocity proper > is). specifically, there was (much) discussion about similarly supporting > tools/toolbox.xml for DVSL. > > that said, we should be *very slow* to tie things firmly to a servlet > environment if we wish to maintain that direction at all. i think it would > be preferable here to either have a ServletToolboxManager interface (with > appropriate default implementation) or, more simply, just require that > anyone plugging their own manager in make it extend ServletToolboxManager. > (personally, i prefer the latter.) > > > By the way, shouldn't the VVS properties be prefixed by > "org.apache.velocity.tools" ? > > eh, that doesn't really follow the pattern of most velocity.props keys. it > would be more inline to prefix VVS properties with something like > "tools.view.servlet". so for the manager, i think > "tools.view.servlet.toolbox.manager.class" would be a good key. > > Nathan Bubna > [EMAIL PROTECTED] > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
