[Springframework-developer] Re: struts integration - alternate approach

[<jue...@we...>]

Dan,
=20
I've just done some prototypical tests. As far as I can tell, the only =
benefit of the RequestProcessor approach is that you can write
=20
  <action path=3D"/test"/>

rather than
=20
  <action path=3D"/test" =
class=3D"org.springframework.web.struts.DelegatingActionProxy"/>
=20
The disadvantage is that you need to have a special subclass of every =
RequestProcessor that you might use: at least of the default =
RequestProcessor and of TilesRequestProcessor. Some amount of code =
duplication is inevitable there. And if you already have a custom =
RequestProcessor, you need to subclass it on your own.
=20
So all things considered, I still tend to recommend the =
DelegatingActionProxy approach, which doesn't affect RequestProcessor =
choice at all. Just saving the "class" attribute above does not seem to =
be enough benefit to accept the RequestProcessor subclass hassle. Is =
there anything I miss here?
=20
Juergen
=20
P.S.:
I'm forwarding this to developer list for further feedback.
=20

________________________________

Von: j=FCrgen h=F6ller [werk3AT]
Gesendet: Mo 26.04.2004 09:11
An: Dan Kokotov
Betreff: Re: struts integration - alternate approach


Hi Dan,
=20
Thanks for the suggestion!
=20
I've actually already considered a RequestProcessor subclass. For =
completeness, it's probably necessary to offer both a subclass of =
RequestProcessor and a subclass of TilesRequestProcessor, delegating to =
Spring-configured Actions in processActionCreate.
=20
I indeed consider adding those classes for Spring 1.0.2. Please send me =
your code to review whether there's anything special that they do that =
my prototypical classes don't.
=20
Regarding your special ActionMapping: Wouldn't it be possible to use =
multiple aliases for the corresponding Spring bean in this case? You =
could then define multiple mapping paths in the Spring bean definition; =
no need for a SpringActionMapping then, if I'm not on the wrong track.
=20
  <bean name=3D"/myaction /myotheraction" .../>
=20
You can separate multiple bean names by space, comma or semicolon =
(according to DefaultXmlBeanDefinitionParser). Does this cover what your =
SpringActionMapping is intended for?
=20
Regards,
Juergen
=20

________________________________

Von: Dan Kokotov [mailto:da...@us...]
Gesendet: Mo 26.04.2004 02:45
An: jho...@us...
Cc: da...@us...
Betreff: struts integration - alternate approach




Hi Jurgen (sorry if i spelled your first name wrong),



First off, just wanted to tell you i think Spring is very

cool. great job!



i noticed that you had incorporated the struts-spring plugin

into spring 1.0.1. I have been using struts and spring

together, and have come up with a different way to glue them

which i think is better. Basically, I have a subclass of

TilesRequestProcessor which overrides the

processActionCreate method to try to look up the action

class in the spring web application context first. if it is

not there, it delegates to the superclass to try to create

it in the usual way. it also provides this functionality for

struts exception handlers. i have also defined a

SpringActionMapping subclass of ActionMapping which allows

you to specify the spring bean name for the action

explicitly, rather than using the path name. this gives you

more flexibility, and is essential if you have multiple path

names mapped into the same action (as for instance when

using a MappingDispatchAction).



the advantage of this approach is that it requires neither a

common base class which has a hardcoded dependency on spring

as well as hardcoded bean names of the services used, nor an

extra action class which just delegates to the real class.



if you are interested in possibly incorporating this into

core Spring, give me your email and i can send you the

relevant classes so it's clearer what i'm talking about.



- dan




d=20