Often parameters are sent over the wire as a group, think of a ' Thanks , i didn't want to have the request parameters as javabeans within
> the Action because they are used only for one-time checks and based on
> their values, some other Action properties are set. The parameter names
> could chan
--- j alex <[EMAIL PROTECTED]> wrote:
> Thanks , i didn't want to have the request parameters as javabeans within
> the Action because they are used only for one-time checks and based on
> their values, some other Action properties are set. The parameter names
> could change later, and i didn't wa
Thanks , i didn't want to have the request parameters as javabeans within
the Action because they are used only for one-time checks and based on
their values, some other Action properties are set. The parameter names
could change later, and i didn't want that to affect the Action.
Now, i tried t
--- j alex <[EMAIL PROTECTED]> wrote:
> HttpServletRequest request = ServletActionContext.getRequest();
> HttpSession session = request.getSession(true);
> if (null != request.getParameter("param1"))
> session.setAttribute("attr1" , true);
> else
> session.setAttribute("attr1" , false);
>
> This w
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
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 i
6 matches
Mail list logo
