When developing web applications you immediately come across the obstacles of the HTTP protocol being stateless. After each request any other request can follow and you cannot rely on a client following a pre-defined sequence of actions. In wizard-like action sequences you can never be sure that the user really executes step 2 after step 1 and step 3 after step 2. The user can always hit the reload or back button of his browser and submit the request associated with step 1 even if you are expecting step 2 right now.

In normal desktop applications you never stumble across issues like that, since there you have modal dialogs available, where the user can never break out. Therefore, what is the logical consequence? You are looking for a mechanism that allows you to implement modal dialogs in web applications...

Unfortunately this is not possible. Implementing modal dialogs in web applications cannot be done, because you do not have any control over the client. You might be able to do some fancy things with JavaScript, but you can never be sure that this works, because you cannot rely on JavaScript to be always switched on in the user's browser. Thus, what normal web applications are supposed to do is: Check on each request if this request is allowed in the application's current state. You can do that manually by hardcoding it into your servlets (or in the Struts sense: in your actions). But as this is an elaborate work that has to be done for each request, it makes sense to build this into the framework you are using for web application development. Thus, why not put it into the most popular framework for Java based web applications: The Struts Framework

With the mechanism that is offered by this extension you can come as close to modal dialogs as you can come: Even though you cannot prevent the user from using his browser's back or reload button, you can at least cope with these cases in a unified way, e. g. display the screen with the dialog, the user is supposed to submit again, until he does. This way you can always rely on the proper sequence of actions being maintained, thus in your actions you can solely concentrate on the functionality and do not have to implement checks to cope with unexpected requests.

Why is a wizard-like sequence of actions difficult to implement and why is there a need to implement modal dialogs? In a wizard-like application sequence you normally ask the user to fill one or more form beans with information by offering him multiple different screens where only a part of the data is entered. The application does not let the user progress to the next screen, until he has filled the previous screen with valid data. This is, because the kind of information that is demanded from the user on the next screen may depend on the data entered on the screen before. With the last step, i. e. when the user finishes the last screen, the information that was gathered step by step is passed on for further processing, e. g. for storing it in a database.

Here are some of the problems the application developer has to cope with, when developing such a multi screen wizard:

• What if the user decides to enter the wizard with the third screen by typing in the corresponding URL manually? Or even more realistic: He uses the browser's back button and returns to the third screen of a wizard (that has been executed and finished before) and hits the submit button. In these situations, the data from the first two steps is not available. In order to cope with these situations gracefully your actions need to be robust enough to tolerate such unexpected requests.
• As the only alternative is the excessive use of hidden fields to carry around data across several screens, normally session scope form beans are utilized to gather the data that is entered during the execution of a multi screen wizard. This is fine, if the user always finishes the wizard regularly, so the session can be cleaned up with the last step. If he leaves the wizard right in the middle, the session data keeps hanging around.
• The reload button problem is not special to wizards, but an issue for all dialogs: If the user hits the reload button, when he has just submitted a form, there is the risk that he does a double-submit which can for instance result in a database record being inserted twice into a database. Even though this issue can be handled with the Struts token mechanism, the Struts Workflow Extension provides an alternative and easier to configure way of preventing this.

This extension is designed to seamlessly fit into the struts framework. All the necessary configuration data for workflow definitions and authentication checks are included in the Struts configuration files. The framework composes of a set of classes which extend the original struts classes. No code modification of the struts framework is necessary. From version 1.0.0 on this extension does not even require you any longer to modify your action classes. The only places that need to be changed are the Struts action definitions in the Struts configuration.

The whole extension is packed in a jar file that can conveniently be included in your application together with the Struts libraries.