> 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]
