Validation errors lost on Redirect Resolution to ActionBean

View: New views
3 Messages — Rating Filter:   Alert me  

Validation errors lost on Redirect Resolution to ActionBean

by Matt Brock :: Rate this Message:

| View Threaded | Show Only this Message

Here's the situation...
I have a submit method in an ActionBean... let's call it MyActionBean.class. If there's an error, I add an error to the Global Errors list, like so:

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:

  1. Please do not tell me to redirect to the JSP. My JSPs are under WEB-INF, where they should be. Thus, redirecting to the JSP exposes the directory in the URL.
  2. Please to not tell me to use a ForwardResolution. A ForwardResolution will bypass data binding logic that occurs in the action.


Re: Validation errors lost on Redirect Resolution to ActionBean

by Ben Gunter-2 :: Rate this Message:

| View Threaded | Show Only this Message

Matt, 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:

Here's the situation...
I have a submit method in an ActionBean... let's call it MyActionBean.class. If there's an error, I add an error to the Global Errors list, like so:

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:

  1. Please do not tell me to redirect to the JSP. My JSPs are under WEB-INF, where they should be. Thus, redirecting to the JSP exposes the directory in the URL.
  2. Please to not tell me to use a ForwardResolution. A ForwardResolution will bypass data binding logic that occurs in the action.

--
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 ActionBean

by Matt Brock :: Rate this Message:

| View Threaded | Show Only this Message

Ben Gunter-2 wrote:
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.
Rats... 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.

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.
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...