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]
