On 4/25/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > 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
yes > * because you don't want to cut-and-paste business logic between the > Action classes. and yes... no, this is not entirely correct. It is not that I did not want to cut-and-paste business logic, I did not want to cut-and-paste UI logic. Also, because Struts action can have only one associated form bean, it seemed natural to split one action into input (setup) action and output action. The understanding that redirection can provide better user experience came later. But now I think this is a natural fit, and I develop all my future Struts apps in the same manner. So far it works. > 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? Umm... Not "from". I can call it anytime, before or after other action. > 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. No, I am not chaining actions to load this, create that, update that and then output that. I input data in the first action, update the model (all business create/delete/update stuff happens here), and in the output action I simply load business object into form bean and display it. > 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. This works for me, since I use redirection and I want actions to be as independent as possible. > The danger is allowing the Actions to become the unit of reuse. The > business facade should be the unit of reuse. With all due respect ;) I cannot agree with that. I reuse actions as UI units, not business units. > 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. Right, but then again, I modularize UI units, not Struts wrappers for my business processes. > 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. That what editAction does, because everything was set up before it is called. The point is, it does not care where the object comes from. If it is not in the memory yet, editAction loads the object from the database. > > 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. As I said, I respectfully disagree. If a particular action does not depend on exact sequence, in what other actions were called before it to set things up, then modularizing actions can be safe and efficient. I myself found my confession, but I would not want others to follow commandments blindly only because they express Creator's will ;) Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
