Menu
▾
▴
springframework-developer
|
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
|
|
From: Mark St G. <stg...@ca...> - 2005-06-17 11:47:38
|
Hi Juergen,
One quick question regarding the reworked Struts Binding support used in
SWF...
Can the Struts binding be used in a non-SWF scenario? (I assume it could,
since SWF is layer above the actual web framework? )
As we all know, FormBeans are still a pain... I just wanted to confirm if
this is a Spring-value add for a Struts app with DomainObject binding...
Thoughts?
Cheers
Mark
"Juergen Hoeller"
<juergen@interfac
e21.com> To
Sent by: <spr...@li...
springframework-d urceforge.net>
eveloper-admin@li cc
sts.sourceforge.n
et Subject
[Springframework-developer] Spring
binding and validation for Struts
06/17/2005 03:37
AM
Please respond to
springframework-d
eveloper
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
|
|
From: Keith D. <ke...@in...> - 2005-06-17 14:03:49
|
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
>
--
Keith Donald
Principal Consultant, Interface21
http://www.springframework.com - Spring Services From the Source
|
|
From: Matt S. <sga...@us...> - 2005-06-17 15:30:44
|
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
>>
>
>
>
|
