struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: design question about action chainning(As quoted in :Struts in Ted Husted et al..)
Date Mon, 03 Feb 2003 11:51:05 GMT
Hi Ted,
This explanatation has set to rest most of my doubts about action 
chainning..And I think the way Most of us use actions(One action to serve the 
request like save action)and another to display the page (like getAccountsList 
Action )is not action chainning but action relay which is perfectly alright.
Also I have understood what u mean by actions becoming API rather than being 
distinations..And this has really helped me to find some of trouble spots in 
our application...

Thanks very very much...For all others as well who have contributed to this 
discussion and helped me (and hopefully a couple others )to better understand 
the very core of struts architecture..


-----Original Message-----
From: husted []
Sent: Friday, January 31, 2003 7:07 PM
To: struts-user
Cc: husted
Subject: design question about action chainning(As quoted in :Struts in Ted Husted et al..)

The best example of waht I'm calling an Action relay is how Struts 
handles validation. If validation fails, the request is forwarded to the 
input property, which could be another Action. This is done to complete 
the response, rather than continue with processing the action.

This same technique is often used after a lookup, where one Action does 
the lookup but another Action is used to complete the response, usually 
to setup any tools the page might need to render.

In an Action chain, control is not forwarded simply to complete the 
response but to continue processing. One action doesn't "do" some 
similar activity because that's the another actions "job". The 
request/response transaction begins to be distributed between several 
Action, and this is where Action stop being destinations and start 
becoming an API.

Most often, whatever processing the Action in a chain are supposed to be 
doing can be refactored into base actions or utility classes, so the 
funcationality can be reused using standard object-orientated techniques.


Ted Husted,
Struts in Action <>

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

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

View raw message