Announcement Announcement Module
No announcement yet.
proper wizard back button handling Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • proper wizard back button handling

    Lets say we have a wizard application with 3 buttons - back, cancel and next. The webflow definition xml file is used to navigate the user after submitting each form - which usually means they clicked on the Next button. For example the flow is:

    flow MAIN
    view A
    view B
    if (x == 1) then A1 else B1
    subflow A1
    view A1.1
    view A1.2
    view A1.3
    subflow B1
    view B1.1
    view B1.2
    view B1.3
    view C

    The user is at "view C" and he clicks on the wizard Back button. The back path(could be A1.x or B1.x) is:

    view B1.3;
    view B1.2;
    view B1.1;
    view B

    So far in the jsp pages the Next and Back buttons where implemented sending generic events like - next and back, mapped in the webflow xml file.
    Is there an execution history list that is accessible to retrieve what was the previous view? Is it possible to go back after executing the subflow end-state?

    What would be the prefered way to handle this?
    At the moment I am sending the user all the way to the "decision-state", skipping over subflow B1.

  • #2
    If you want 'exact' back behaviour like this, subflows are a problem. Remember that a subflow acts as a black box as far as the parent is concerned, so that makes it hard to do something like you describe.

    However, a subflow state allows you to specify the start state of the subflow to use, so that might help you. You would probably need a custom SubflowState subclass that overrides the getSubflowStartState() method and looks up the correct state to go back to (e.g. because it's id was mapped when the subflow finished).

    You could also have a flow execution listener keep track of the 'history' and use that to do the back stuff in some way.

    Still, the simplest way to do it is just not use subflows if you need this kind of thing.



    • #3
      If that is the case then the flow concept is really kind of a one way street when it comes to handling sub-flows and web application with back button implementation.
      Would it be possible that you add a configuration option which will force the state machine to remember the sub-flow entry point and merge the sub-flow with the main flow. In other words, at that point, you do not expire the sub-flow and it becomes part of the flow. If the state machine remembers the entry point, that would solve the above case where you could have sub-flow A1 or B1. In this case the sub-flow would expire only after the user went all the way back to "viewB". Let say the user clicked on the back button all the way to "viewB" and the user makes changes to the form and with the new changes in the form the "decision-state" goes different path, then at that point the state machine would replace and expire B1 with A1.


      • #4
        This is not something we're targetting at the moment, but SWF was designed to be extremely flexible, so it might well be possible. I'd say: go ahaid and give it a try, then let us know how it turned out!

        Also take a look at WFNM (, which is a simple tag lib that helps in doing this kind of thing.



        • #5
          I am sorry it took me while to answer - was on vacation.

          When you have support in the configuration file for "if else" and subflows you should threat "Next" and "Back" application buttons equally. Otherwise the framework offers inconsistence model - very good support for going forward but no support for going back.

          >>This is not something we're targetting at the moment, but SWF was >>designed to be extremely flexible, so it might well be possible.

          I understand that and I could try to hack something together, but I am afraid that the design in the framework currently is not there to support that - I mean the configuration file is loaded and parsed before the flow starts, which means that providing dynamic functionality for the "Back" button would be somewhat difficult. The idea is to provide support for the Back button in the config file not in the jsp files, otherwise the configuration model is broken.