On 7/6/05, Rick Reumann <[EMAIL PROTECTED]> wrote: > Michael Jouravlev wrote the following on 7/6/2005 5:03 PM: > > > The action class > > provides the event contract, while the action form does the dirty > > work. > > Well in this case the struts-config file would provide the contract and > you could simply use one ForwardAction for everything. You've > substituted numerous Actions (or DispatchAction methods) and replaced > them with either A) numerous ActionForms (probably sharing the same > field names or B) complext logic in single ActionForms to decide on what > 'business logic' to do.
I cannot use ForwardAction for everything because I need to dispatch the button click to a handler. DispatchAction (its subclass) provides dispatching of events. My ActionForms do not have complex logic, they have simple methods like crudCreate or crudLoad or crudDelete. These methods are called from action class. Action class itself can be reused in different apps or in the same app, because it is stateless. ActionForm is stateful (has session scope), has specific business code and properties for every particular business object. Generally, actionforms are not shared. > > Did I convince you that having business logic in an action form is > > better? Action class provides external I/O contract and manages > > messages and navigation, while action form performs operations on > > business data, *where it is actually stored* . > > No you haven't convinced me at all:) I still see no practical benefit to > flipping struts inside out like this. I just explained where benefit is: with your approach you reuse forms, but define specific action classes. I suggest to reuse action classes, but to define specific forms. Is not it the same thing? I don't think so, because action classes can define different contracts, for example for yes/no dialog, or for next/back/cancel wizard of for create/edit/view/delete form. These action classes can be reused. Action form works with specific data, so it is natural, that it should not be reused. I will think of better reasons ;) > (I don't think the method names "reset" and "validate" would be chosen as > method names in an ActionForm if they were designed for doing all kinds > of business logic in them. Oops, I see misunderstanding here. I did not say that business logic should be implemented in reset and validate. Not at all. There are intefaces, which are implemented by action forms. I hope you will find time to look at my stuff, because it is explained there and in the source code. > I think if you go this route, you should say it's a different version of > Struts.. maybe StrutsWorks or something:) You got me: I was thinking of spawning off Struts to something else, but I would like first to convince its power users and committers, that the change I am suggesting is good. If this does not work, I may consider borrowing Struts core, add my stuff to it and call it StrutsWorks ;) I figured, that to do that I need at least 30% of my own code, and now I do not have critical mass yet. Another issue is users, who would learn new controller framework, when there are exciting alternatives like Wicket? > Under the scenario you've > proposed I don't see what the point of using any Actions would be? Why > not just use the one default FowardAction and do everything in the > ActionForm? Right, in many cases I would prefer action form to do the dispatching and forwarding to a view. But in other cases I would prefer to reuse standard action class, and to define business methods in a form bean. So, I don't want to *change* everything, I want to *add* new options. Michael. -- Dialogs for Struts http://struts.sourceforge.net/strutsdialogs --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
