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. B -----Original Message----- From: Par Winzell [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 3:36 PM To: Struts Users Mailing List Cc: 'Par Winzell' Subject: RE: using redirecting forwards after failed validation Barett, > 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 /gui.do when she first enters her search data, and validation fails, then I believe the URL should still read /gui.do for the second attempt, rather than /executesearch.do 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! Zell --------------------------------------------------------------------- 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]
