Menu
▾
▴
Re: [Springframework-developer] Re: struts integration - alternate approach
|
From: <jue...@we...> - 2004-04-28 08:10:14
|
Essentially, using DelegatingActionProxy or DelegatingRequestProcessor = even becomes a configuration-time choice then: Both access = Spring-configured Action beans in the ContextLoaderPlugIn context. I = wouldn't mind adding the RequestProcessor subclasses, although they = clearly have the disadvantage of interfering with a custom = RequestProcessor. However, most people will use either Struts' default = RequestProcessor or the TilesRequestProcessor, so we'd definitely cover = more than 90%. The rest can still use DelegatingActionProxy, just = needing to adapt struts-config accordingly. =20 Juergen =20 P.S.: How late is it in Denver? 4 o'clock in the morning? ;-) =20 ________________________________ Von: spr...@li... im Auftrag = von Matt Raible Gesendet: Mi 28.04.2004 10:01 An: spr...@li... Betreff: RE: [Springframework-developer] Re: struts integration - = alternate approach +1 for adding them to the org.springframework.web.struts package. I use XDoclet for all my Actions in AppFuse and therefore, I'm not using the ContextLoaderPlugIn. I'd like to use it b/c then I can use MockStrutsTestCase to test my actions. This change would make it possible. Matt > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] > On Behalf Of j=FCrgen h=F6ller [werk3AT] > Sent: Wednesday, April 28, 2004 1:36 AM > To: spr...@li... > Subject: Re: [Springframework-developer] Re: struts > integration - alternate approach > > > 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, > > > > 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 > > > > <action path=3D"/test"/> > > > > rather than > > > > <action path=3D"/test" > > class=3D"org.springframework.web.struts.DelegatingActionProxy"/> > > > > 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. > > > > 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? > > > > Juergen > > > > 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=3D> 12297 > > _______________________________________________ > > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... > Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id149&alloc_id=8166&op=CCk > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
