On the subject of one Action calling another, one option that is often overlooked is to simply instantiate another Action yourself and call process() on it manually. I.e., in Action A do:
Action ab = new ActionB(); ab.process(m f, r, r); The benefit to this is that you don't need to go through the request processing chain again, and you can determine whether you want to use the forward returned by the called Action (Action B above) or the one generated by the Action doing the calling (Action A above). Don't take this as an endorsement of this approach though, merely as an FYI on another option. What Ted eloquently says about a proper business API facade should make this option irrelevent as well as the others. But if you have it in your head that you need/want to chain Actions, this is another way to do it, one with some benefits that might be important to you. I've done this myself on occassion to no ill effect (although I fight myself when I think of doing it now!) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 25, 2005 7:09 am, Ted Husted said: >> in my sample CRUD application i have editAction, which displays an >> item in HTML form. It takes item ID as parameter. This action is >> mapped, it can be called directly from a page using link, like >> editAction.do?ID=1234. Another way to call it is to call it from >> createAction, which creates new item, assigns in ID to it, and >> redirects to editItem with ID attached to the URL as query parameter. >> Is this chaining? > > The question is whether you are > > * going from one to the another because you need to redirect anyway, or > * because you don't want to cut-and-paste business logic between the > Action classes. > > If the latter, then the business API is underdeveloped and the > application is on a slipperly slope. > > The key point is: Could you call the editAction business logic from > another Action class if need be? > > The main reason that Action Chaining is bad is because it implies > people are not creating their own business APIs: The Action classes > are becoming the API rather than an adaptor to the API. Another reason > is simply because Struts was not designed to support Action Chaining > and, out of the box, can't distinguish between a new request and a > "chained" request. > > The danger is allowing the Actions to become the unit of reuse. The > business facade should be the unit of reuse. The Actions should be an > adapter between HTTP and your application's API. There should be a > very clear line where Struts ends and your business logic begins. As > Steve McConnell would say: Program into Struts, not with Struts. > > In this case, it should boil down to a method call on a business > object that takes an ID and returns the value object we want to edit. > If that is what the heart of the Action does, then the application is > on the right road. If the Action goes through several lines of setup > and teardown code, that you would not want to maintain elsewhere, then > the application is on the road to ruin :) > > If it's a short road, then there may be little or no harm. But, if it > is a long road, then there will be problems along the way. > >> This works great and allows to add a level of abstraction, so editItem >> does not know where the data comes from. This modularized approach >> allows to create application with high level of reuse. > > As mentioned, the focus should be on the business object that editItem > calls, not the editItem Action. The business objects should be the > unit of reuse, and Actions merely adaptors. > > >> >> Michael. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- > HTH, Ted. > > --------------------------------------------------------------------- > 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]
