Another way to go would be to provide a "API object" in the request that the tags, or any other presentation technology, could use to access framework resources.
In this way, no one else would need to the various special locations, only where to find the API object.
This was the idea behind the "ConfigHelper", which we put together when the Velocity/Struts tools was first being discussed.
I love this. I actually hadn't seen it before. We had talked briefly a few days ago about a "StrutsContext" as the argument to Action.execute() and Renderer.render() -- but it looks to me like this class is everything I would expect that one to be... Unless it was assumed that StrutsContext would implement o.a.c.chain.Context, which may be a good idea -- haven't thought about it that much.
Where is this actually being used now? Just in the Velocity tools? I think the struts-chain stuff might be clearer if they all passed a ConfigHelper instance along instead of each needing to know the context key under which various items would be found. I'm assuming from the design of the struts-chain commands that someone may have thought there was a good reason to keep that more flexible -- perhaps for interaction with unforeseen commands -- but sometimes I think that makes it more complicated than it needs to be.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining."
-- Jef Raskin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
