Gabe said: [snip] > > at present, the tools we've talked about are all request oriented or global > > (aka static). in the velstruts app i've developed, one of the tools i wrote > > is only session sensitive. > > > What does this tool? I am curious because I couldn't think of any such > tool.
well, the simplest example would be a tool that accesses user information loaded into the session (we always have tools like this our Turbine/Velocity apps). such tools needed only be initialized when the user logins in (starts a new session), but the only session tool i currently have in a Struts/Velocity app is a FoodlistTool. it's only responsibility is accessing and analyzing a list of Food objects that is stored in the session. once the tool has been initialized and grabbed a reference to the foodlist from the session, it doesn't need reinitialized. > > as for the scope being 'fixed by the design', i don't think that must > > necessarily be true. if my proposed behavior is accepted, i would happily > > make DateTool implement ContextTool so that instances returned by > > 'getInstance' would look for a Locale in the request or session to use > > instead of the default. that way, those developers who wish to use DateTool > > as global (statically) or request scope may simply specify the desired scope > > in the config file. > > > I see your point in theorie. I am just not convinced yet that it > addresses are real need. I cannot imaging a real-world tool where > the scope it not fixed by the design of the tool. DateTool isn't real-world? hmm. perhaps if you describe what you mean by a 'real-world tool' then i'll be able to think of an example. granted, i think tools which can reasonably vary in scope will be the exception rather than the rule, and you can certainly solve the DateTool situation i describe by having people who want a request scope DateTool extend the current version to implement the appropriate interface. However, i would prefer to avoid putting people in situations like that, and i don't see the harm in allowing them to specify scope in toolbox.xml. there's just something intuitive to me about that (perhaps due to time spent using Turbine). besides, i like being able to look at the config file and see what scope each tool is without have to look at each file. i guess the bottom line(s) IMO is: -the present treatment of tools is inadequate. -we would be mistreating and ignoring a significant class of tools by not supporting session scope tools. -there isn't really any serious need for supporting variable scope tools. however, i think that it could definitely come in handy sometimes, and i still don't see the harm in it. at the very least, it would allow us to provide a more useful and flexible DateTool. for custom tools created by developers, this will probably almost always be a moot point as they'll have easy control over the source of their tools. > > ...in any case, i would > > suggest that we make the default scope (the setting if no scope is specified > > in the config) be request. > > Well, in one of your last mails you convinced my of the opposite ;-) > Assuming request scope might seem to be safe default behavior, BUT > if a tool doesn't implement any interfaces it won't be able to get > an parameters passed from the tool manager. If it doesn't get any > parameters, it doesn't interact with the environment. Isn't it pretty > safe to assume that in such a situation the tool is global? yeah, it is. i don't know what i was thinking. > With my current understanding I would vote for global scope as default. you're quite right. > Ok, I'll wait for your code and then will go from there. soon now... Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
