Announcement Announcement Module
Collapse
No announcement yet.
Implementing redirect-after-post with AbstractWizardFormController Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Implementing redirect-after-post with AbstractWizardFormController

    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

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

  • #2
    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

    Comment


    • #3
      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

      Comment


      • #4
        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.

        Comment


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

          Thanks,

          Norm

          Comment


          • #6
            Could you please clarify how you solved this issue?

            Originally posted by nonak View Post
            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?

            Comment

            Working...
            X