struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Barett McGavock <>
Subject RE: using redirecting forwards after failed validation
Date Wed, 17 Dec 2003 23:03:23 GMT
You are correct.

Your decision to put the errors in the session is necessary if you want the
URL to read that way. My understanding is that all request attributes will
vanish if you redirect. Most notably including the ActionErrors that the
thread was all about! :) I have long since given up trying to control what
the URL line reads, in favor of preserving a slim session. But this is one
of the many tradeoffs we all make with Struts.

Also a small problem with the code that I originally submitted that would
make this more obvious:
-  saveErrors(errs);
+  saveErrors(request, errs);

Thanks for the comments.

-----Original Message-----
From: Par Winzell [] 
Sent: Wednesday, December 17, 2003 3:36 PM
To: Struts Users Mailing List
Cc: 'Par Winzell'
Subject: RE: using redirecting forwards after failed validation


> 1) keep the ActionErrors as a request attribute
> 2) set the validate parameter to false for the ActionMapping
> 3) add code like the following to the search action itself: errs = 
> form.validate(); if (!errs.isEmpty()) {
>   saveErrors(errs);
>   return mapping.getInput();
> }

This seems like forcing a flow that's supposed to be the framework's
supposed to deliver... but clearly it's very similar to what the
RequestProcessor already does, so it sounds like an acceptable compromise.

> A note: this solution will forward to your input page, not redirect. 
> I'm not entirely sure from your message on why you'd like to redirect 
> to the input. It sounds like you're not set on it, so maybe a forward 
> like the above will do.

If the user's URL reads / when she first enters her search data, and
validation fails, then I believe the URL should still read / for the
second attempt, rather than / or whatnot.

That does require a redirect, right?

Anyway, your solution should work equally well while storing the errors in
the session context. Many thanks!


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message