|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
|
|
Validation errors lost on Redirect Resolution to ActionBeanHere's the situation... getContext().getValidationErrors().addGlobalError(new SimpleError("YOU SCREWED UP!"));When I return the redirect, I make sure to flash the current ActionBean's state: return new RedirectResolution(MyActionBean.class, "view").flash(this); This used to work like you would expect. Now, the errors are lost--my guess is that the bean that's passed along is subsequently overwritten on redirect, throwing away all the saved data. This used to work fine in 1.4.3, but in the 1.5 branch I have yet to get it to work. Additionally:
|
|
|
Re: Validation errors lost on Redirect Resolution to ActionBeanMatt, you were unwittingly taking advantage of a bug in 1.4.3 by doing this. Prior to 1.5, ActionBeans that were flashed were not getting a new ActionBeanContext so they were seeing information from the previous request instead of the current request. See: http://www.stripesframework.org/jira/browse/STS-565
One side effect of correcting that bug is that validation errors cannot be carried over on a flash/redirect. If the validation errors were to carry over and be added to the ActionBeanContext on the new request, they would short-circuit the lifecycle and try to go back to the source page and generally wreak havoc. We explored various ways to maintain that backward compatibility, but it just wasn't possible. The only reason it worked in 1.4.3 is because the ActionBean had one ActionBeanContext (containing errors) and the ExecutionContext had another (with no errors). Unfortunately, various parts of the code get the context from both places so they need to be the same. That was always the intention anyway. You'll need to change your approach to this problem. You can use messages instead of errors, as they do carry over on a flash/redirect. Or you can probably write an interceptor that runs before event handling to place the errors from the previous context into the new context before you forward to your view. As much as you don't want to hear it, the best thing to do is forward instead of redirect. If you need some input on how to accomplish what you need to accomplish with a forward instead of a redirect, you can toss it out to the list for consideration. -Ben On Thu, Jul 24, 2008 at 11:17 AM, Matt Brock <brockmatt@...> wrote:
-- Ben Gunter ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Validation errors lost on Redirect Resolution to ActionBeanRats... that's a real pity for those of us who like to keep our JSPs under WEB-INF. Is there any reason you can't treat errors the same way you treat messages (throwing it into some kind of _SPECIAL_REQ_PARAM)? Also, I appreciate that you at least tried to maintain backwards compatibility... unlike some superannuated jerks I could mention. Won't this completely bypass any binding you might handle in a @Before/@After interceptor? Further, doesn't this make the Redirect-After-Post technique impossible? I suppose I'll end up using the messages to take errors as well until I can think of something better. Thanks for your help... |
| Free embeddable forum powered by Nabble | Forum Help |