Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-04-28 07:40:22
|
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 |
|
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 |
|
From: <jue...@we...> - 2004-04-28 18:32:43
|
OK, I'll commit them tomorrow morning - please give them a try once = they're in CVS, to verify that they address your needs. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Seth Ladd Sent: Wednesday, April 28, 2004 8:05 PM To: spr...@li... Subject: Re: [Springframework-developer] Re: struts integration - alternate approach j=FCrgen h=F6ller [werk3AT] wrote: > 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 I definitely vote +1. I'd love to throw away our implementation and use = a Spring-blessed implementation. Thanks! Seth ------------------------------------------------------- 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.=20 http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Seth L. <se...@eh...> - 2004-04-28 21:39:58
|
jürgen höller [werk3AT] wrote: > OK, I'll commit them tomorrow morning - please give them a try once they're in CVS, to verify that they address your needs. > Will do. Thanks! Seth |
|
From: <jue...@we...> - 2004-04-29 07:16:32
|
Just committed them: There's = org.springframework.web.struts.DelegatingRequestProcessor and = org.springframework.web.struts.DelegatingTilesRequestProcessor now - = check out the javadoc for details. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Seth Ladd Gesendet: Mi 28.04.2004 23:39 An: spr...@li... Betreff: Re: [Springframework-developer] Re: struts integration - = alternate approach j=FCrgen h=F6ller [werk3AT] wrote: > OK, I'll commit them tomorrow morning - please give them a try once = they're in CVS, to verify that they address your needs. > Will do. Thanks! Seth ------------------------------------------------------- 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_id=3D3149&alloc_id=3D8166&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Matt R. <li...@ra...> - 2004-04-28 08:01:45
|
+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...=20 > [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=20 > integration - alternate approach >=20 >=20 > I see. > =20 > I wonder whether it's worth adding a=20 > DelegatingRequestProcessor and a=20 > DelegatingTilesRequestProcessor to our=20 > org.springframework.web.struts package then: That approach is=20 > mainly useful when generating struts-config via XDoclet, if I=20 > understand correctly. Of course, quite a lot of people do use=20 > Struts with XDoclet. > =20 > What does everybody think? I've got those RequestProcessor=20 > subclasses lying around already; the question is whether to=20 > include them in Spring 1.0.2. Else, I'll add them to the=20 > sandbox for the time being. Votes, please :-) > =20 > Juergen > =20 >=20 > ________________________________ >=20 > Von: spr...@li... im=20 > Auftrag von Seth Ladd > Gesendet: Mo 26.04.2004 23:54 > An: spr...@li... > Betreff: Re: [Springframework-developer] Re: struts=20 > integration - alternate approach >=20 >=20 >=20 > j=FCrgen h=F6ller [werk3AT] wrote: > > Dan, > >=20 > > I've just done some prototypical tests. As far as I can=20 > tell, the only=20 > > benefit of the RequestProcessor approach is that you can write > >=20 > > <action path=3D"/test"/> > > > > rather than > >=20 > > <action path=3D"/test"=20 > > class=3D"org.springframework.web.struts.DelegatingActionProxy"/> > >=20 > > The disadvantage is that you need to have a special=20 > subclass of every=20 > > RequestProcessor that you might use: at least of the default=20 > > RequestProcessor and of TilesRequestProcessor. Some amount of code=20 > > duplication is inevitable there. And if you already have a custom=20 > > RequestProcessor, you need to subclass it on your own. > >=20 > > So all things considered, I still tend to recommend the=20 > > DelegatingActionProxy approach, which doesn't affect=20 > RequestProcessor=20 > > choice at all. Just saving the "class" attribute above does=20 > not seem=20 > > to be enough benefit to accept the RequestProcessor=20 > subclass hassle.=20 > > Is there anything I miss here? > >=20 > > Juergen > >=20 > > P.S.: > > I'm forwarding this to developer list for further feedback. >=20 > Juergen, >=20 > For our integration here, we ended up subclassing=20 > RequestProcessor. The reason was because we're using xdoclet=20 > to build our struts-config.xml file. So IIRC we couldn't use=20 > DelegatingActionProxy (or the similar > alternatives) because we needed Xdoclet to read into our=20 > action classes. >=20 > Hope that helps, > Seth >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: The Robotic Monkeys at=20 > ThinkGeek For a limited time only, get FREE Ground shipping=20 > on all orders of $35 or more. Hurry up and shop folks, this=20 > offer expires April 30th!=20 > http://www.thinkgeek.com/freeshipping/?cpg=3D> 12297 >=20 > _______________________________________________ >=20 > Springframework-developer mailing list=20 > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market...=20 > Oracle 10g.=20 > Take an Oracle 10g class now, and we'll give you the exam FREE.=20 > http://ads.osdn.com/?ad_id149&alloc_id=8166&op=CCk > _______________________________________________ > Springframework-developer mailing list=20 > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 |
|
From: Seth L. <se...@eh...> - 2004-04-28 18:05:12
|
jürgen höller [werk3AT] wrote: > I see. > > 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. > > 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 :-) > I definitely vote +1. I'd love to throw away our implementation and use a Spring-blessed implementation. Thanks! Seth |
