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]
