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]
