related to: Re: #2 - Use DispatchAction to organize related operations

[Rick Reumann <ma...@reumann.net>]

On Friday, May 31, 2002, 7:11:47 AM, Ted Husted wrote:

TH> The Struts Dispatch Action is designed to do exactly the same thing, but
TH> without messy branching logic. The base perform method will check a
TH> dispatch field for you, and invoke the indicated method. The only catch
TH> is that the dispatch methods must use the same signature as perform.
TH> This is a very modest requirement, since in practice you usually end up
TH> doing that anyway.

    Ted, I was discussing with James Mitchell about ways to manage a
    user being logged in and he suggested a way that I really liked
    where you have a base class perform method handle checking the
    login status and then call something like a doWork() method that
    will invoke the work in your subclass Actions (avoiding have to
    have all your actions handle the loggin check).

    The question I have is I'm now using a dispatch action class that
    handles most of the action work. Do I need to go in and modify the
    base DispatchAction class' perform method in order to get
    something similar to the above functionality? Or maybe there is an
    easier way to handle checking login status using a subclass of
    DispatchAction?

    Thanks

--

Rick

mailto:maillist@reumann.net

"Probably the earliest flyswatters were nothing more than some sort of
striking surface attached to the end of a long stick."
  -Jack Handey


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re[2]: related to: Re: #2 - Use DispatchAction to organize related operations

[Chuck Cavaness <ch...@attbi.com>]

The processPreprocess() method has the request and response as arguments, 
so you should be able to get everything you need. Remember, the method 
returns a boolean that tells the RequestProcessor whether it should 
continue to process the request or not. If you find that the user is not 
logged in, you'll need to return false, but also redirect the user 
manually. You can still get access to the GlobalForwards and such; it's 
just that you'll need to take care of the redirecting part. You can call 
the processActionForward() method and pass it the ActionForward for the 
login page, for example.

Chuck

At 11:04 PM 6/3/2002 -0400, you wrote:
>On Monday, June 3, 2002, 10:58:07 PM, Chuck Cavaness wrote:
>
>CC> What I suggest is to look at the processPreprocess() method in the
>CC> RequestProcessor and possibly override this to do your checks. It's 
>called
>CC> for every request and long before ActionForm's are populated and Action's
>CC> are invoked. The default value is to return true, which allows request
>CC> processing to continue. What I've done in the past is to override this,
>CC> check the login, and possibly redirect the user to the login page. If the
>CC> user's logged in, just return true to continue processing the request.
>
>     Excellent idea. Thanks. You are right I wouldn't even want form
>     validation to take place if they weren't logged in ( which would
>     be allowed to happen if I only checked in the action ). I take it
>     I'll have access to the session as well inside of
>     RequestProcessor, because if I go this route I will also need to
>     check for particular roles that will be stored in a UserBean put
>     in the Session and possibly deny or grant access based on these
>     roles.
>
>--
>
>Rick
>
>mailto:maillist@reumann.net
>
>"I wish I had a dollar for every time I spent a dollar, because then,
>Yahoo!, I'd have all my money back."
>   -Jack Handey
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re[2]: related to: Re: #2 - Use DispatchAction to organize related operations

[Rick Reumann <ma...@reumann.net>]

On Monday, June 3, 2002, 10:58:07 PM, Chuck Cavaness wrote:

CC> What I suggest is to look at the processPreprocess() method in the 
CC> RequestProcessor and possibly override this to do your checks. It's called 
CC> for every request and long before ActionForm's are populated and Action's 
CC> are invoked. The default value is to return true, which allows request 
CC> processing to continue. What I've done in the past is to override this, 
CC> check the login, and possibly redirect the user to the login page. If the 
CC> user's logged in, just return true to continue processing the request.

    Excellent idea. Thanks. You are right I wouldn't even want form
    validation to take place if they weren't logged in ( which would
    be allowed to happen if I only checked in the action ). I take it
    I'll have access to the session as well inside of
    RequestProcessor, because if I go this route I will also need to
    check for particular roles that will be stored in a UserBean put
    in the Session and possibly deny or grant access based on these
    roles.

--

Rick

mailto:maillist@reumann.net

"I wish I had a dollar for every time I spent a dollar, because then,
Yahoo!, I'd have all my money back."
  -Jack Handey


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: related to: Re: #2 - Use DispatchAction to organize related operations

[Chuck Cavaness <ch...@attbi.com>]

Rick,

  Let me mention something. One potential problem with this approach is 
that by the time the action is called, may be too late. You really need to 
catch this earlier. I had implemented something along these lines awhile 
back and soon remembered that the ActionForm is populated and the 
validate() method is called, all of this before the Action's execute() 
method is invoked. The question is, do you want to check whether or not the 
user is logged in after this, or before it. Maybe this is app specific, I'm 
not sure. It's my opinion, and only an opinion, that you really should be 
catching this before the action is invoked, if nothing else, for security 
reasons.

What I suggest is to look at the processPreprocess() method in the 
RequestProcessor and possibly override this to do your checks. It's called 
for every request and long before ActionForm's are populated and Action's 
are invoked. The default value is to return true, which allows request 
processing to continue. What I've done in the past is to override this, 
check the login, and possibly redirect the user to the login page. If the 
user's logged in, just return true to continue processing the request.

Just some things to think about,
Chuck

At 09:31 PM 6/3/2002 -0400, you wrote:
>On Friday, May 31, 2002, 7:11:47 AM, Ted Husted wrote:
>
>TH> The Struts Dispatch Action is designed to do exactly the same thing, but
>TH> without messy branching logic. The base perform method will check a
>TH> dispatch field for you, and invoke the indicated method. The only catch
>TH> is that the dispatch methods must use the same signature as perform.
>TH> This is a very modest requirement, since in practice you usually end up
>TH> doing that anyway.
>
>     Ted, I was discussing with James Mitchell about ways to manage a
>     user being logged in and he suggested a way that I really liked
>     where you have a base class perform method handle checking the
>     login status and then call something like a doWork() method that
>     will invoke the work in your subclass Actions (avoiding have to
>     have all your actions handle the loggin check).
>
>     The question I have is I'm now using a dispatch action class that
>     handles most of the action work. Do I need to go in and modify the
>     base DispatchAction class' perform method in order to get
>     something similar to the above functionality? Or maybe there is an
>     easier way to handle checking login status using a subclass of
>     DispatchAction?
>
>     Thanks
>
>--
>
>Rick
>
>mailto:maillist@reumann.net
>
>"Probably the earliest flyswatters were nothing more than some sort of
>striking surface attached to the end of a long stick."
>   -Jack Handey
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>