Is there a reason it has to happen in an action? This looks to be a bit more suited for an interceptor. I try to separate (logically) the processing by thinking along these lines - If the processing is happening on a business object, handle it in an action. If the processing is affecting the state of the user/request/server, do it in an interceptor. Interceptors are a bit better suited for getting the raw request and session objects.
That being said, you can mask the session by using the SessionAware interface. This will make the session a Map, thus making it more POJOy. http://struts.apache.org/2.x/docs/how-do-we-get-access-to-the-session.html To get request parameters in a more POJOy way, you have a few choices. First, add getters/setters to your action. The parameters will be passed (and converted if necessary) to the action via the setters. If for some reason you don't know the names of the parameters until runtime, you can try the ParameterAware interface - http://struts.apache.org/2.x/docs/how-can-we-access-request-parameters-passed-into-an-action.html -Wes On Sun, 2008-02-10 at 13:54 -0500, j alex wrote: > Hi, > > What's the best practice to refer to request and session within an S2 Action > without tying it to HttpServletRequest or HttpSession ? > > Assume that we need to capture values from certain request parameters and do > some processing based on them, and set session attributes : > > Currently, i'm doing it like : > > HttpServletRequest request = ServletActionContext.getRequest(); > HttpSession session = request.getSession(true); > if (null != request.getParameter("param1")) > session.setAttribute("attr1" , true); > else > session.setAttribute("attr1" , false); > > This works, but we now have references to HttpServletRequest and HttpSession > which goes against the S2 "POJO" action / testability benefits etc. (even > though i may not write a TestCase at all) > > What's the best way to do this, so that the Action remains independent of > http ? > > Thanks, > Joseph --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
