Re: StrutsContext/ConfigHelper (was Re: Making Struts Build Easier)
On Fri, 26 Mar 2004 11:32:20 -0800, Craig R. McClanahan wrote: > Quoting Joe Germuska <[EMAIL PROTECTED]>: > Wouldn't the context object used by struts-chain contain everything > you might need in Velocity-land? It would be a shame to invent a > second "context" object if we're going that direction anyway and it > can meet your needs. I'm not sure that Joe's a Velocity Tools user himself. I believe he was just picking up on my reference. Right now, the Velocity Tools expose several different objects that roughly equate to the Struts taglibs. So you can expose the tool you need, in the same way you can import the taglib you need. Taken together, these tools have most of the functionality that we might find in a full-featured ActionContext. Another term for such tools would be view helpers. Nothing fancy. Just a JavaBean, really. There's a nifty loading mechanism though, so you load up whatever tools of your own that might be needed. (Say, a database access tool.) If an ActionContext were exposed in the request, it's true that something like the Velocity Tools for Struts probably wouldn't be needed. A surprising amount of functionality would also be exposed to JSLT, JSF, and any other view technology out there. (Say, Jelly for example.) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StrutsContext/ConfigHelper (was Re: Making Struts Build Easier)
Quoting Joe Germuska <[EMAIL PROTECTED]>: > At 7:00 AM -0500 3/26/04, Ted Husted wrote: > >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. > Wouldn't the context object used by struts-chain contain everything you might need in Velocity-land? It would be a shame to invent a second "context" object if we're going that direction anyway and it can meet your needs. > Joe Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StrutsContext/ConfigHelper (was Re: Making Struts Build Easier)
On Fri, 26 Mar 2004 07:56:11 -0600, Joe Germuska wrote: > 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 The ConfigHelper was never actually used by Velocity Tools, except to show where all the bodies were buried. I very much doubt that anyone is actually using it right now. Like a lot of things, it's just continuation of many things that we've done all along. We already put the ActionMapping in the request. This puts "Struts" in the request :) I've renewed development of this class over to Commons Chain, where work has begun on a "Struts MailReader for Commons Chain" example application. http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/chain/apps/mailreader/ I think in the 1.3 era, where Commons Chain is part of the core, we could in fact base an ActionContextBase on a.o.c.chain.ContextBase. There could also be a clean-room interface that exposed things like Messages and Mappings and Validators (oh my!), to a business Command, but not the http interface or contexts. -Ted. On Fri, 26 Mar 2004 07:00:57 -0500, Ted Husted wrote: > On Thu, 25 Mar 2004 08:22:48 -0600, Joe Germuska wrote: > >> As I've been saying (a lot, it seems, lately) on struts-user, I >> think there are legitimate Struts JSP tags like "html:messages" >> that are not best replaced by JSTL. Any time Struts tools put >> resources in special locations in request or session scope, I >> think it's nice to have tags which know the special locations, >> instead of expecting people to dig in and find them. And, for >> example with html:messages, the message-property filtering is a >> useful feature that would require a lot of verbose JSTL to >> achieve the same goal. >> > > 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. > > > http://tinyurl.com/yshnp > > > It's never been updated for modules, but if it were, the idea would > be that it would return references to whatever resources were > appropriate to a given module. > > >> From the perspective of a presentation technology, regardless of >> its nature, the ConfigHelper (or ActionContext) would be Struts, >> in the same sense that a JBDC driver appears to be the database. >> (Adapter/proxy patterns.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
StrutsContext/ConfigHelper (was Re: Making Struts Build Easier)
At 7:00 AM -0500 3/26/04, Ted Husted wrote: 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]
