We think Struts power lies in its simple and rigorous design process. If you combine Struts-Tiles, you will have the display Action for the whole page and actions for all included tiles. Actions are controllers that can have parameters set in the configuration file. With careful design of helper beans (ActionForm is a helper bean) and class structures for both actions and helper beans, which we call processing containers, you can bring the set parameters to your business processes that change per action.
An example may help to illustrate this simple but powerful process inherent in Struts that makes it so popular. A user may initially be authenticated via username and password that you assign as authenticationLevel1. When the user requests a certain action such as money transfer and/or sending a legal-binding contract, you may decide to further challenge the user identity with a personalized token (what user has). Struts-Tiles action allows you to do this at individual action level. In this example, you just assign the action at authenticationLevel2. Your controller will send the further challenge before serving the requested action. It remembers the user requestURL so if the challenge passed, it serves what user asked, etc. The same concept can apply to the required communication level for each action so you can appropriately serve each request based on what user wants, etc. You don't have to be 1 size fit all. We love this simple and rigorous process and do not want to break its design principal. Have a good day and good weekend. :-) BaTien ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, January 31, 2003 1:44 AM Subject: Re: design question about action chainning(As quoted in :Struts in action...by Ted Husted et al..) > Hi, > I agree with u that u can have another layer of abstraction(like helper beans) > between action and Service layer.So that same code ecan be reused. > But this some disadvangates. > Firstly U are then not really using the power of Struts Configuration file > which allows you to use logical mappings in Action classes And to change the > Flow,U can just change the config file (So long as all required parametzers are > being passed in new flow as well..).Because in our project, we had this > requirement many a times.After we had done one release, the business gusy will > come up with a suggestion some thing like, After AccountDetails PAge, can we go > to AccountList üpage instead of Summary page etc etc .And because of Reusable > actions, this was just a matter of changing the struts config file and in one > of cases may be make the new caller pass a few more parameters.But there was no > code duplication. > > So as i said in my original mail,If your services are not tied to actions, then > in that case I don't see any problem in action chainning.ANd it seems to me the > best thing to really harness the power of Struts..Or is there any other > preformance or design issue which i have missed? > > Any comments:-))?? > > > regards, > Shirish > > -----Original Message----- > From: batien.duong [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 30, 2003 5:09 PM > To: struts-user > Subject: Re: design question about action chainning(As quoted in :Struts > in action...by Ted Husted et al..) > > > We achieve what you describe as a chain of actions for re-use with helper > beans and follow Struts design principal as Ted described. The helper beans > can be ready in cache or service pool for reuse. Look at > http://myportal.myb2cb2b.com/com.dbgroups.ppf/model/web/dao.html > > Hope this may help. > BaTien > > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, January 30, 2003 3:34 AM > Subject: design question about action chainning(As quoted in :Struts in > action...by Ted Husted et al..) > > > > Hi All, > > I have a very basic design question about struts action design..We have > been > > developing a fairly large and complex web application involving struts and > > struts has proved to be a great help :-)) But after reading the book by > Mr. > > Husted et al., "Struts in action",I have some basic questions about the > way we > > have done our project and the way it is described in the book. > > TO quote Mr. Husted...(Section 8.4 Chaining Actions .Note at the end of > > Section8.4.1. Starting fresh..) > > ************************************************************ > > Speaking as a Software architect,chainning actions in any way is not > something > > that I like to do.Ideally you should be able to call the business objects > from > > any Action where they are needed.Wanting to forward control to another > action > > implies that the Business object my be too tightly coupled.Or it may > imply > > that the actions should descend from a common super class with hotspots > that > > sub classes should override....There are occasions when chainning actions > makes > > sense-for example if the other action is being used to render the response > in > > lieu of a presentation page.But valid use cases are rare.The best general > > practice is to stay with one-request ,one action regimen. > > ************************************************************* > > > > > > And also after searching the archives for action chainnign , I found > another > > reply from Mr. Husted which says.. > > ******************************************************************** > > Wanting to chain actions is a warning sign that there is too much business > > logic is creeping into the Actions and they are becoming the API, rather > than > > an adaptor for the API. (Struts should not *be* your application, it > should be > > a gateway *to* your application.) > > > **************************************************************************** > **** > > ************************* > > > > > > I have a high regard for Mr. Ted Husted and that's why I would like to > clarify > > some of my doubts about the design strategy he has advocated in his book > from > > the exüperienced users of this list and Mr Husted himself if possible. > > I dont understand what is the disadvantage in Chainning actions?HAs it > some > > thing to do with performance?I totally agree that the business objects > shuld > > not be tightly coupled with actions and should be callable from any where > .But > > even after following this principal, most of the time you will end up > chainning > > actions if u really want reusable actions.Example can be loging process of > a > > user.So the request for loging form a user can result in 2 actions being > > called.1:CheckLogin(which checks user credentials) It forwards control to > > 2:getUserAccountList which gets the list of accounts for the user. > > > > So now the getUserAccountList action I can call from any where else by > passing > > right params and it becomes reusable.But if i had done all of this(check > log in > > and then get accunts)in login action, i need to write another action to > get > > account for another page.And I am using calls to different > > services(LoginService and AccountService..)which are still reusable from > any > > action here.. > > So the chainning of actions this way has perfectly solved all the > > problems...And instead of this being a rare iuse case, most of the time , > this > > is the pattern u will have for any use case.(Update some thing and get > some > > data to screen...)So what is the advantage of following one-request ,one > > action regimen? > > > > Also I didnt understand what he means by (Struts should not *be* your > > application, it should be a gateway *to* your application.)As I see it,the > > service layer handles the business logic .But Ultimately the actions end > up > > delegating the requests to service and so doing error handling as well as > > handling flow control(Some thing like if this error, go to page 1, for > that > > request go to page 2..)So they are very much part of the > application...Infact > > they handle the application flow.Is this right or Am i missing some thing > very > > bascic here? > > This is important as We have the next phase of development starting next > week > > and we are in the process of evaluating our architecture and finding any > > flaws..So any help will be highly appreciated... > > > > Sory for being tooo verbose.But i couldn't have exlained it any other way. > > > > regards, > > Shirish > > -------------------------------------------------------- > > Shirish Sakhare > > Application Developer > > (CEFS PROJECT) > > (CEFS) Corporate Employee Financial Services > > > > UBS AG > > Stauffacherstrasse 41 > > P.O. Box, CH-8004 Zürich > > Tel: +41-1-235 56 31 > > Fax: +41-1-235 54 21 > > Personal Mail Id:[EMAIL PROTECTED] > > -------------------------------------------- > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
