struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Siggelkow <>
Subject Re: Question on Command implementations
Date Sun, 06 Mar 2005 04:27:11 GMT
Well, in looking at the Command implementations, I will say that the 
pattern of usage appears to be quite consistent. The abstract commands 
only refer to the ActionContext; the concrete sub-classes initially 
downcast to ServletActionContext and work with that object. My guess is 
that there are places where a concrete command *must* delve into the 
Servlet API. So you would end up with some classes that needed to 
downcast to ServletActionContext and some that didn't -- an 
inconsistency that might not be worth it.

On 2005-03-05 22:42:50 -0500, Joe Germuska <> said:

> At 7:52 PM -0500 3/5/05, Bill Siggelkow wrote:
>> I apologize if this has been discussed in the archives. But I was 
>> wondering if there was a reason why the command implementations did not 
>> use the getSessionScope methods as opposed directly acquiring the 
>> HttpSession. For example, in SelectLocale it seems that:
>> HttpSession session = saContext.getRequest().getSession();
>> Locale locale = (Locale) session.getAttribute(Globals.LOCALE_KEY);
>> could have been rewritten as:
>> Locale locale = (Locale) saContext.getSessionScope().get(Globals.LOCALE_KEY);
>> thereby removing reliance on  the Servlet API.
>> My apologies if this is a stupid question ...
> It's just a side effect of incremental refactoring -- it looks like 
> you've identified yet another possible increment.
> However, as far as I'm concerned, anywhere where "Globals" is used 
> should probably be "inverted" so that instead, a typesafe property is 
> declared on the ActionContext.  There should be no need for "special 
> knowledge" of the keys under which things are stored when you have an 
> object like the ActionContext, which encapsulates the request and 
> (implicitly) the session.
> I guess it's time for another run-through the classes to see where 
> things like this have slipped through.
> The next logical step is to define a ApplicationContext bean which does 
> an equivalent encapsulation of things stored in the ServletContext.  
> Perhaps based on the current design, it would be more appropriate to 
> consider this a Module level encapsulation instead of serving for the 
> entire application.  I haven't thought too deeply about this one yet.
> Joe

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message