|
From: Juergen H. <ju...@in...> - 2005-06-17 08:37:54
|
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
|