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

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

I see.
=20
I wonder whether it's worth adding a DelegatingRequestProcessor and a =
DelegatingTilesRequestProcessor to our org.springframework.web.struts =
package then: That approach is mainly useful when generating =
struts-config via XDoclet, if I understand correctly. Of course, quite a =
lot of people do use Struts with XDoclet.
=20
What does everybody think? I've got those RequestProcessor subclasses =
lying around already; the question is whether to include them in Spring =
1.0.2. Else, I'll add them to the sandbox for the time being. Votes, =
please :-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Seth Ladd
Gesendet: Mo 26.04.2004 23:54
An: spr...@li...
Betreff: Re: [Springframework-developer] Re: struts integration - =
alternate approach



j=FCrgen h=F6ller [werk3AT] wrote:
> 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.

Juergen,

For our integration here, we ended up subclassing RequestProcessor.  The
reason was because we're using xdoclet to build our struts-config.xml
file.  So IIRC we couldn't use DelegatingActionProxy (or the similar
alternatives) because we needed Xdoclet to read into our action classes.

Hope that helps,
Seth



-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=3D12297
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer