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]
