There is another benefit to the way that struts does things. Since the actionform has such a heavy structure, standard actions can be written based on the structure. If a common set of business actions can be defined then actions can be reused across large sections of a web enabled application, i.e. wizards, reports, lookup-save-saveas-delete, etc. Then business object can implement these simple interfaces, dropped into an actionform and off you go.
Edgar > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Saturday, December 20, 2003 5:47 PM > To: Struts Developers List > Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum) > > > I think that sounds like a good compromise. In my view, > there are really two types of "forms" - small ones with one > or two parameters, and full blown complex input forms. In > the former case, I think combining the form and action is a > good idea; the latter, probably not so much. > > In WebWork2/XWork, as I understand it, your action can > declare JavaBean setters which will be automatically > populated by the framework. This makes it very easy to unit > test and frees the actions from any servlet dependencies. > This approach works very well for actions that require a > couple of parameters, while I might favor the Struts approach > for larger forms. > > To experiment adding these and other WebWork2/XWork features > in Struts we started the Struts Action Invocation Framework > (SAIF) on struts.sf.net > The Struts sf site is a great forum for trying out ideas > before sticking them in Struts core. To implement the > integrated form/action, we "scope" actions > (request/session/application), then use action interceptors > to set action JavaBean setters from the request parameters. > While SAIF certainly isn't ready to be put in Struts core, > the action interceptor idea is showing promise and provides a > good alternative to the more heavy-handed ActionForm for > simplier situations. > > Don > > > > > Hack might be too strong a word. I'd call it a reasonable > alternative > > extension of the framework :) > > > > If we want to look at the WebWork/Maverick approach of > using a single > > input/command handler, where Struts has separate input and command > > handlers, why not add the said standard ExecuteFormAction and > > ExecuteForm subclass to the build and see how the community reacts? > > > > After 1.2.0 rolls, we could add them to the nightly build and mark > > them experimental. When 1.2.1 comes around, we could then decide > > whether to leave them or pull them. If we decide to pull > them, we can > > always start that toolkit on SourceForge, and let it live there. > > > > Or, if the community likes the idiom, then in 2.x we could > provide the > > ExecuteForm behavior without providing an Action to do it. > > > > -Ted. > > > > > > Don Brown wrote: > >> Yes, it is possible to do a lot of things with Struts > currently, but > >> for the most part, they are all hacks. With Struts 2.0, we have a > >> chance to look at Struts best practices, other web frameworks, and > >> current technologies to design Struts to be the best and easiest > >> framework for web applications, and perhaps beyond. My > point is we > >> should look at whether to encourage through Struts design and > >> documentation the combination of forms and actions, or keep the > >> current design. In this process, I think it is important > to look at > >> other frameworks and the results of the design choices they made, > >> particularly our close cousin WebWork2/XWork. > >> > >> Don > >> > >> On Sat, 20 Dec 2003, Ted Husted wrote: > >> > >> > >>>Don Brown wrote: > >>> > >>>>Hmm...I'm not familiar with that discussion, but I don't see why > >>>>general form functionality couldn't be defined in an > interface, but > >>>>the ActionForm > >>>>left how it is. Of course we also have a chance to do > what Craig said > >>>>he'd change about Struts (at JavaOne 2003 JSF BOF) and > combine forms > >>>> and > >>>>actions. WebWork2/XWork seems to have done well with > that approach. > >>> > >>>It's been mentioned on the list that you can combine Actions and > >>>ActionForms already. All that's needed is an ActionForm > subclass with > >>>an execute property, and a standard Action that simply > returns that > >>>result > >>>instead: > >>> > >>>ExecuteForm ef = (ExecuteForm) form; > >>>return ef.execute(request,response,mapping,form); > >>> > >>>-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] > >> > >> > > > > > > > > > --------------------------------------------------------------------- > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
