You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Bill Siggelkow <bi...@bellsouth.net> on 2005/03/06 01:52:50 UTC
Question on Command implementations
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 ...
-Bill Siggelkow
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Question on Command implementations
Posted by Bill Siggelkow <bi...@bellsouth.net>.
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 <Jo...@Germuska.com> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Question on Command implementations
Posted by Craig McClanahan <cr...@gmail.com>.
For some additional prior art, you might want to take a look at:
* javax.faces.context.ExternalContext
* org.apache.commons.chain.web.WebContext
Craig
On Sat, 5 Mar 2005 20:05:43 -0800, Martin Cooper <mf...@gmail.com> wrote:
> On Sat, 5 Mar 2005 21:42:50 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> > 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.
>
> Just FYI, the Portlet spec (JSR 168) has a convenient list of all of
> the methods that are common to both ServletContext and PortletContext.
> Makes it easy to put together a common interface for both. ;-)
>
> --
> Martin Cooper
>
>
> > 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
> >
> > --
> > Joe Germuska
> > Joe@Germuska.com
> > http://blog.germuska.com
> > "Narrow minds are weapons made for mass destruction" -The Ex
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Question on Command implementations
Posted by Martin Cooper <mf...@gmail.com>.
On Sat, 5 Mar 2005 21:42:50 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> 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.
Just FYI, the Portlet spec (JSR 168) has a convenient list of all of
the methods that are common to both ServletContext and PortletContext.
Makes it easy to put together a common interface for both. ;-)
--
Martin Cooper
> 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
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Question on Command implementations
Posted by Joe Germuska <Jo...@Germuska.com>.
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
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org