struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edgar P Dollin <ed...@blue-moose.net>
Subject RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Date Sun, 21 Dec 2003 05:50:48 GMT
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: mrdon@twdata.org [mailto:mrdon@twdata.org] 
> 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: struts-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >> 
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Mime
View raw message