oh yes, yes, it would include those parameters in the request, but I'd have to figure out some OGNL that would add actionErrors and fieldErrors as parameters for the redirect, then if my Action-being-redirected-to extends ActionSupport the setters should automatically be called.
I think this would be done often enough that it could be built into the Result. At this point, however, the default behavior of not doing POST-redirect-GET for validation errors seems to work just fine for me. So I think I'll only do POST-redirect-GET on successful POSTs which pass validation. Brad Cupit Louisiana State University - UIS -----Original Message----- From: Guillaume Bilodeau [mailto:[EMAIL PROTECTED] Sent: Thursday, April 10, 2008 8:06 PM To: user@struts.apache.org Subject: RE: interesting proxy + action chain issue I'm not sure if I'm missing something here, but using the ServletActionRedirectResult with parse=true and extra parameters does include these parameters in the redirect URL. The problem is that this mechanism is limited to string-based (or string-parseable) parameters, so you're ruling out objects like an ArrayList that would contain error messages. That's where something like flash scope would be useful and is unfortunately lacking in 2.0. Cheers, GB Brad A Cupit wrote: > > Hi Guillaume, > yep, I'm familiar with the ServletActionRedirectResult, and I'm > especially familiar with bug you mentioned (you and I both commented on > it, asking for a backport to 2.0.x...on that note, anyone with commit > access want to backport https://issues.apache.org/struts/browse/WW-2170 > and release 2.0.12? The patch is there and ready to go) :-) > > What I'm not sure how to do is to get the error messages into the > redirect url, and it seems like something you'd want often enough for it > to be built-in to ServletActionRedirectResult (or a class which extends > it). > > Brad Cupit > Louisiana State University - UIS > > > -----Original Message----- > From: Guillaume Bilodeau [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 10, 2008 1:24 PM > To: user@struts.apache.org > Subject: RE: interesting proxy + action chain issue > > > Hi Brad, > > Have you tried this: > http://www.vitarara.org/cms/struts_2_cookbook/post_and_redirect > > I've used this for a while with good results, although recently I've > stumbled on WW-2170 ( https://issues.apache.org/struts/browse/WW-2170 ). > It > seems to occur only when using annotations though. > > Cheers, > GB > > > Brad A Cupit wrote: >> >> The only problem with the scope plugin is that it will use the > session, >> which may break the whole notion of POST-redirect-GET: if the data in >> the session is removed or replaced by later requests, then pressing > the >> back or refresh buttons on the initial page with errors will not yield >> the same response. >> >> I think it would be cool if the errors were url parameters as part of >> the redirect, but there's currently no easy way to do this. Could a >> custom interceptor realize that the result is a redirect and turn the >> validation errors into url parameters? Or would this need to be a > custom >> result class (perhaps extending ServletRedirectResult or >> ServletActionRedirectResult)? >> >> Brad Cupit >> Louisiana State University - UIS >> >> -----Original Message----- >> From: Jeromy Evans [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, April 08, 2008 6:24 PM >> To: Struts Users Mailing List >> Subject: Re: interesting proxy + action chain issue >> >> Ian Meikle wrote: >>> HI, >>> >>> I have been following this post with interest since I used the PRG >> pattern >>> in previous projects. >>> We are using struts 2 in are current project and I like the >> errorMessages >>> behaviour that is part of the Action. >>> >>> Is it possible to persist these over the PRG cycle ? >>> By default I assume they would be lost when we get to the GET stage >> since >>> they are request scope and the GET is a seperate request than the > POST >> >>> that caused the error. >>> >>> >> >> Hi Ian, >> This is an issue that Struts2 needs to handle better. It can be done >> but its not as straight-forward as it could be. >> >> The scope interceptor [1] provides this feature. It allows you to >> specify which properties should be bound to session or application > scope >> >> and injected into the action. >> The scoped modeldriven interceptor is for modeldriven actions [2]. > Both >> >> are included in the default stack. >> >> The scope plugin allows annotations to specify which properties > persist >> over a cycle. It's not bundled with struts but I have heard good >> comments about it [4]. >> >> [1] http://cwiki.apache.org/WW/scope-interceptor.html >> [2] http://cwiki.apache.org/WW/scoped-model-driven-interceptor.html >> [3] http://cwiki.apache.org/S2PLUGINS/scope-plugin.html >> [4] http://article.gmane.org/gmane.comp.jakarta.struts.devel/65052 >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > -- > View this message in context: > http://www.nabble.com/interesting-proxy-%2B-action-chain-issue-tp1654447 > 2p16612701.html > Sent from the Struts - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/interesting-proxy-%2B-action-chain-issue-tp1654447 2p16623232.html Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
