RE: design question about action chainning(As quoted in :Struts in action...by Ted Husted et al..)
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.. regards, Shirish -Original Message- From: husted [mailto:[EMAIL PROTECTED]] Sent: Friday, January 31, 2003 7:07 PM To: struts-user Cc: husted Subject: design question about action chainning(As quoted in :Struts in action...by 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. -- Ted Husted, Struts in Action http://husted.com/struts/book.html - 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]
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 overrideThere 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
RE: design question about action chainning(As quoted in :Struts in action...by Ted Husted et al..)
Hi, Does this mean that using action forwards To point another action is not action chainning?So we can call this action relay and its in line with Struts design principles? And as u said,We have really abstracted away all error handling etc to Abstract Action class.But the point is if we go withoput action chainning(or if we call it action relay),then to get the same page from different work flows,U may need to copy the same code to call service in muiltiple action classes. my question is what is the real disadvantage of using Atomic actions , if the are designed proper struts way(USing struts techniques so that they are not dealing with HTTP but directly getting objects from form beans..As u rightly said...)And then forward from one atomic action to another to complete a work flow.. regards Shirish -Original Message- From: husted [mailto:[EMAIL PROTECTED]] Sent: Friday, January 31, 2003 12:34 PM To: struts-user Cc: husted Subject: RE: design question about action chainning(As quoted in :Struts in action...by Ted Husted et al..) Derek Richardson writes: But you still have to duplicate code in the actions, right? Even if that code is as simple as: Service service = Service.getService(SERVICE_KEY); Foo[] foos = service.getFoos(); request.setAttribute(FOO_KEY, foos); Action chaining allows this code to be written once and used many times. Thus you get reuse of presentation code, not just business logic. Personally, I would put utility code like this in a super class and make it available to whatever Action wanted to call it. Actions are instantiated once, and there is no performance penalty for have a deep hierarchy. So there would be something like setService(request) that any Action could call. The BaseAction in Scaffold makes good use of this technique for error handling and such. What happens with true Action chaining (not to be confused with a simple Action relay) is that instead of using Java calls to create our presentation API, we start to use HTTP to make the API calls instead. IMHO, this is a step backward. The point of Struts is to get us up and out of HTTP and into an object-orientated domain, where we can write proper programs. (Rather than an endless chain of kludges.) -Ted. -- Ted Husted, Struts in Action http://husted.com/struts/book.html - 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]
RE: design question about action chainning(As quoted in :Struts in action...by Ted Husted et al..)
Ted, can you (or someone else) clarify the difference b/t action chaining and action relay? Thanks, Greg -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Friday, January 31, 2003 5:34 AM To: [EMAIL PROTECTED] Subject: RE: design question about action chainning(As quoted in :Struts in action...by Ted Husted et al..) Derek Richardson writes: But you still have to duplicate code in the actions, right? Even if that code is as simple as: Service service = Service.getService(SERVICE_KEY); Foo[] foos = service.getFoos(); request.setAttribute(FOO_KEY, foos); Action chaining allows this code to be written once and used many times. Thus you get reuse of presentation code, not just business logic. Personally, I would put utility code like this in a super class and make it available to whatever Action wanted to call it. Actions are instantiated once, and there is no performance penalty for have a deep hierarchy. So there would be something like setService(request) that any Action could call. The BaseAction in Scaffold makes good use of this technique for error handling and such. What happens with true Action chaining (not to be confused with a simple Action relay) is that instead of using Java calls to create our presentation API, we start to use HTTP to make the API calls instead. IMHO, this is a step backward. The point of Struts is to get us up and out of HTTP and into an object-orientated domain, where we can write proper programs. (Rather than an endless chain of kludges.) -Ted. -- Ted Husted, Struts in Action http://husted.com/struts/book.html - 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]
Re: design question about action chainning(As quoted in :Struts in action...by Ted Husted et al..)
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 overrideThere 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
RE: design question about action chainning(As quoted in :Struts in action...by Ted Husted et al..)
Ted, will you give me your opinion on my post of Mon 1/27/2003 5:21 PM with a subject of RE: Two ActionForms colliding on property name? I am wondering whether you see my splitting of actions into post-actions and pre-actions as action relays or action chaining. To use the input attribute in validation to point to a previous action, the input element needs to point to what I call a pre-action but not the post-action. So this requires a separation between pre-actions and post-actions. I am not arbitrarily partioning the request/response transaction; I am drawing a well-defined line between processing necessary to complete the last user/system interaction and processing necessary to initiate the next user/system interaction. Overall, I am not grokking your division between completing the response and continuing processing. Perhaps because, in my mind, completing the response requires continued processing and why continue processing if not to complete the response (unless it is to complete the request, as in my post-action). -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Friday, January 31, 2003 1:07 PM To: Struts Users Mailing List Subject: design question about action chainning(As quoted in :Struts in action...by 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. -- Ted Husted, Struts in Action http://husted.com/struts/book.html - 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]
RE: design question about action chainning(As quoted in :Struts in action...by Ted Husted et al..)
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 overrideThere 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
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 overrideThere 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,
RE: design question about action chainning(As quoted in :Struts in action...by Ted Husted et al..)
But you still have to duplicate code in the actions, right? Even if that code is as simple as: Service service = Service.getService(SERVICE_KEY); Foo[] foos = service.getFoos(); request.setAttribute(FOO_KEY, foos); Action chaining allows this code to be written once and used many times. Thus you get reuse of presentation code, not just business logic. -Original Message- From: BaTien Duong [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 30, 2003 11:09 AM To: Struts Users Mailing List 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 overrideThere 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
