The test application included in the Workflow Extension package is meant both for testing and demonstrating the package's features. It provides a graph, the user can only traverse along well defined paths. As this may be a little bit abstract to many people, there is also a more realistic demo application that demonstrates, how the Struts Workflow Extension can be used to implement a wizard-like sequence of dialogs.

Here is, what the test application does: After having logged in with an arbitrary user name, the applicaton shows two workflows that can be traversed by clicking on the arrows that lead to a new state (in the image below the application is in state 1 of workflow 3):

Examples for valid paths in WF1 are the following:

• WF1-1WF1-2WF1-3End
• WF1-1WF1-2WF1-2WF1-2WF1-3End
• WF1-3End

There are only two valid paths how to step through WF2 and WF3:

• WF2-1WF2-2WF2-3End
• WF2-1WF2-2WF3-1WF3-2WF2-3End

When stepping through a workflow, the path that was currently taken in this workflow is displayed to the user as well as the number of actions that were executed already in this workflow. The paths and the variable keeping the number of actions are stored in the user's m.session and are cleaned up, when a workflow ends (either because it ends normally or a workflow violation is encountered).

The three workflows WF1, WF2 and WF3 behave similar when a prevState violation is encountered, i. e. when the user tries to jump into a workflow right in the middle: In this case the start action of the workflow is executed.

The three workflows behave differently when a nextState violation is encountered, i. e. the user is in the middle of a workflow and tries to break out:

If the user violates WF1, the workflow is cleaned up and the action that was originally requested is executed just like if WF1 had not been active when the action was initially requested. Thus, the user is not held captive in WF1. Still all the cleanup tasks are executed when the workflow is left without being finished normally, i. e. the path the user took in WF1 is cleaned from the session.

WF2 and WF3 behave different: They do not allow the user to leave the workflow. The user must step through and cannot break out by any means. Whenever he tries, he is brought back to the beginning of either WF2 or WF3.

WF3, demonstrates how a modal dialog normally works. When the user is in the state WF3-1 and tries to execute a different action than the one that leads to WF3-2, he is brought into the state WF3-1 again. Think of WF3-1 being the state the application enters, when displaying a modal dialog and WF3-2 is the state the workflow enters, when the user submits this modal dialog: No matter which action the user executes, he is always brought back to the one that displays the modal dialog, until he executes the action that submits this dialog.

After having downloaded the source code refer to the installation instructions to build and deploy the test application or directly download the test application struts-workflow-x-y-z-test.war and deploy it in your JSP container. Then point your browser to the following url to display the application's login page:

http://[server]/[context-path]/displayLoginAction.do

Look into the file struts-config.xml in order to understand how the workflow is controlled.

Just a few remarks here:

It is always the same page that is displayed after having executed an action that leads to a different state: inHome.jsp. There is quite some java code in this file which could be extracted in tag libraries. This was not done in order to keep everything in one place.

The attributes that are put into request scope from each action don't have to do anything with the workflow functionality. Their mere purpose is to control what inHome.jsp displays (i. e. to highlight the state the application is currently in). So don't get confused with these attributes. They are not needed to control the workflow between the actions that make up the application.