Implementing redirect-after-post with AbstractWizardFormController

[deanen]

I'm familiar with the RedirectView and the "redirect:viewname" syntax but don't know how to apply it to an AbstractWizardFormController. I know it is not as simple as

   setPages(
         new String[] { "redirect:Step1", "redirect:Step2", "redirect:Step3" });

By default, AbstractWizardFormController simply forwards (RequestDispatcher.forward) to the next view in the wizard which leads to the nasty reposting of requests if the user clicks the back button.

[nonak]

I m having the same issue, we are trying avoid re-submitting the same data when user press the refresh button. For instance the form uploads a picture and return to the same page. If user press the refresh button the picture is added twice.

I guess this would not happen if the redirect-after-post would apply... but how can we achieve with a basic AbstractWizardFormController ?

Thanks for your help

[joshk]

Hi deanen and nonak,

The problem you are both trying to resolve is not a new one, and its interesting to see you are both trying to use the tried and tested post-redirect-get solution, which is great.

The only problem is that the AbstractWizardFormController was not built for stateful web conversations. Its true that it was built for wizard style interactions, but for proper web conversations where clicking refresh, hitting back a few times, and using logic to determine the next page is important you should instead use Spring Web Flow.

Spring have long said that for stateless interactions and simple CRUD activities Spring MVC is perfect (read more here), but for more complex workflows or where having the post-redirect-get idiom taken care of for you (and soooooo much more), Web Flow is better suited.

I know that this is not a quick simple solution which can fix your problems with a simple line change, but learning SWF is very valuable in the long run. I recommend the Ervacon Spring Web Flow book which, although is a bit old (since SWF 2.0 is about to come out), can still be considered the bible on SWF.

Hope this helps

Josh

[nonak]

Well thanks for taking time to answer this post. At least it clarifies the point. We can't afford refactoring the application with SWF so we have a very basic token implementation which does the job for the simple issue we are facing.

Thanks again for your message.

[deanen]

Thanks for the advice Josh. I hadn't checked the forums in a while but had arrived at the same conclusion.

Thanks,

Norm

[Neomusashi]

Well thanks for taking time to answer this post. At least it clarifies the point. We can't afford refactoring the application with SWF so we have a very basic token implementation which does the job for the simple issue we are facing.

Thanks again for your message.

Could you please clarify how you solved this issue?
What does your token implmentation do?