[Springframework-developer] Re: Spring binding and validation for Struts

[Matt S. <sga...@us...>]

I prefer the Delegating Action mechanism which defines Struts Actions in 
the Spring application context.  To me this is the most natural solution 
because then Struts Actions are beans just like anything else in a 
Spring application.  It's very conceptually simple.

I think Spring should only provide a single mechanism to inject 
dependencies into Struts actions.  This is easiest for users of Spring 
because there's only one mechanism to learn and no choices to make. 
It's also easiest for the development team because only one mechanism 
needs to be coded, tested, maintained and documented.  Since the current 
Delegating Action mechanism has been around for a long time, I think it 
would make the most sense to keep it and not introduce new ways to 
inject dependencies into Struts Actions.

Matt

Keith Donald wrote:
> Awesome, Juergen, glad to see this cleanup here as I was always in to what
> that code was doing (allowing us to use Spring's data binding with Struts)
> but never really happy with the implementation.  Nice work.
> 
> I think the autowire option is important enough to keep in.  It really is
> the simplest way to get DI on your actions.
> 
> Keith
> 
> 
>>I've now also given a Juergen treatment ;-) to the Spring
>>binding/validation
>>adapter for Struts that Keith committed to the main source tree.
>>
>>For everybody not familiar with this from the Web Flow side of things: The
>>idea here is to allow for using Spring's DataBinder/Errors mechanism
>>within
>>a Struts web tier, seamlessly exposing the result to traditional Struts
>>views (with "html:form", "html:errors", etc).
>>
>>I've significantly reworked this: In contrast to its original inception
>>where there've been a special RequestProcessor, a special PlugIn and a
>>special ActionForm, what's left now is - a single SpringBindingActionForm
>>adapter. SpringBindingActionForm cares for everything necessary: from
>>extending Commons BeanUtils to exposing the Spring-managed errors as
>>Struts
>>ActionMessages.
>>
>>There is no special RequestProcessor necessary anymore, which I consider
>>as
>>a must: Too many Struts extensions subclass the RequestProcessor
>>themselves,
>>including Tiles and our own Delegating Action mechanism.
>>
>>The final usage style looks as follows. In "struts-config.xml", a single
>>ActionForm is defined for all Actions:
>>
>><form-beans>
>>  <form-bean name="actionForm"
>>type="org.springframework.web.struts.SpringBindingActionForm"/>
>></form-beans>
>>
>>In each Struts Action that wants to use Spring binding/validation for a
>>plain POJO form object, the following pattern can be used:
>>
>>public ActionForward execute(ActionMapping actionMapping, ActionForm
>>actionForm, HttpServletRequest request, HttpServletResponse response)
>>throws
>>Exception {
>>  SpringBindingActionForm form = (SpringBindingActionForm) actionForm;
>>  MyPojoBean bean = ...;
>>  ServletRequestDataBinder binder = new ServletRequestDataBinder(bean,
>>"myPojo");
>>  binder.bind(request);
>>  form.expose(binder.getErrors(), request);
>>  return actionMapping.findForward("success");
>>}
>>
>>Keith/Erwin, please give this reworked version a try in Web Flow's Struts
>>adapter. As far as I can see, it should still work nicely for those needs.
>>
>>---
>>
>>Regarding the further Struts support classes added alongside the
>>binding/validation support:
>>
>>The TemplateAction class essentially duplicated what our existing
>>ActionSupport already did, plus a view convenience mirrors of static
>>utility
>>methods (which I consider unnecessary - why not access the corresponding
>>static RequestUtils methods directly). The "preExecute" and "postExecute"
>>are fine in general, but it's not Spring's business to provide such Struts
>>stuff that's not related to Spring mechanisms... Hence, I've dropped
>>TemplateAction completely.
>>
>>DependencyInjectedAction, which autowires the Action instance by type, is
>>not a bad idea. I don't think that it should be a dedicated class, though,
>>so I've removed it as well. If we intend to recommend such an autowiring
>>pattern for Struts Actions, we should build it as an option into the
>>existing ActionSupport class. However, there's DispatchActionSupport and
>>Lookup/MappingDispatchActionSupport as well, so we'd need to duplicate
>>quite
>>a bit...
>>
>>Note that we also offer a Delegating Action mechanism, which completely
>>defines Struts Actions in a Spring context. Of course, any kind of
>>autowiring is available to those instances already. Hence, I'm not sure
>>whether we should provide yet another dependency injection for Struts
>>Actions out-of-the-box. If we consider this important enough, I won't
>>mind,
>>but we should strive for integrating this into the existing
>>XxxActionSupport
>>classes - if at all.
>>
>>Juergen
>>
>>
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>>informative Webcasts and more! Get everything you need to get up to
>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
> 
> 
>