You've stated it correctly when you said that Actions are your flow controllers. In the case of your login/getAccounts example, you should have a business object that handles login, and a business object that gets accounts. You would then have a login action (use case controller) that would use both business objects, assuming the login was successful. You would also have a displayAccounts action (use case controller) that uses the accounts business object very similar to the way the login action uses it.
So, my understanding is that the Actions you define are your use case controllers. They basically give you all the options you have with your application, but the logic of the application itself resides in the business objects. You may have lots of actins with some repeated code in a few, or you may be able to define just a few "parameterized" actions that handle all your use cases somewhat generically. Now, the case you've defined is that the outcome of one use case causes another use case to be executed. While I probably wouldn't check for a login that way, I'm not yet convinced that the approach itself is inherently bad. BTW, I don't see actions as "handling errors" so much as responding to them, and acting as an adapter layer between your application's error handling and Struts. You should probably have some error-handling mechanism in your business layer and the Action classes will interpret what comes out of the business layer and translate it into Struts errors. Greg > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 30, 2003 4:34 AM > To: [EMAIL PROTECTED] > 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]
