Another thing to consider is that the business functionality may not always be best
expressed in straight Java. Integrating rules engines and/or XML service invocations
is somewhat cleaner if the action and form are separate.
hab
-----Original Message-----
From: Edgar P Dollin [mailto:[EMAIL PROTECTED]
Sent: Sun 12/21/2003 12:50 AM
To: 'Struts Developers List'
Cc:
Subject: RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
