Those are the only two requirements: each view wishing to participate in an executing
flow must submit the _flowExecutionIdparameter to associate itself with the correct flow
execution and _eventIdparameter to tell that execution what happened in the resuming
view state.
Listing 11-16 contains an example of a view participating in a flow execution by submit-
ting back the necessary parameters via hidden form parameters.Listing 11-16.Example JSP to Continue an Existing Flow<html>
<head><title>Example page to continue a flow</title></head>
<body>
<form method="POST" action="/purchase.htm"><input type="hidden" name="_flowExecutionId" value="${flowExecutionId}"/>
<input type="button" name="_eventId_submit" value="Submit"/>
</form>
</body>
</html>This example shows use of the special eventIdbutton name prefix, which allows Spring
Web Flow to obtain the_eventIdwithout JavaScript when using multiple submit buttons
within a single form.Launching the Flow from the Browser
With the knowledge you have now, you are ready to execute an instance of the Product Purchase
flow from your web browser. To launch a new flow execution, simply point it at the URL of the
FlowController, parameterizing the URL with the flow to execute:
http://localhost:8080/purchase.htm?_flowId=purchase-flow
Each time you hit that URL, a new flow purchase-flowexecution will be launched and
transitioned to its start state. When the execution reaches a view state, control will be returned
to the client to allow the user to participate in the flow. Subsequent requests to the server must
provide the _eventIdand the_flowExecutionIdto specify what happened in what conversation.■Tip You can think of the flowIdas analogous to the name of a class, while the flowExecutionIdis
analgous to an object reference.This ping-pong between the view and Spring Web Flow can be visualized as shown in
Figure 11-6.332 CHAPTER 11 ■INTRODUCTION TO SPRING WEB FLOW