When a flow enters a view-state it pauses, redirects the user to its execution URL, and waits for a user event to resume. Events are generally signaled by activating buttons, links, or other user interface commands. How events are decoded server-side is specific to the view technology in use. This section shows how to trigger events from HTML-based views generated by templating engines such as JSP, Velocity, or Freemarker.
The example below shows two buttons on the same form that signal proceed and cancel events when clicked, respectively.
<input type="submit" name="_eventId_proceed" value="Proceed" /> <input type="submit" name="_eventId_cancel" value="Cancel" />
When a button is pressed Web Flow finds a request parameter name beginning with _eventId_ and treats the remaining substring as the event id.
So in this example, submitting _eventId_proceed becomes proceed.
This style should be considered when there are several different events that can be signaled from the same form.
The example below shows a form that signals the proceed event when submitted:
<input type="submit" value="Proceed" /> <input type="hidden" name="_eventId" value="proceed" />
Here, Web Flow simply detects the special _eventId parameter and uses its value as the event id.
This style should only be considered when there is one event that can be signaled on the form.
The example below shows a link that signals the cancel event when activated:
<a href="${flowExecutionUrl}&_eventId=cancel">Cancel</a>
Firing an event results in a HTTP request being sent back to the server.
On the server-side, the flow handles decoding the event from within its current view-state.
How this decoding process works is specific to the view implementation.
Recall a Spring MVC view implementation simply looks for a request parameter named _eventId.
If no _eventId parameter is found, the view will look for a parameter that
starts with _eventId_ and will use the remaining substring as the event id.
If neither cases exist, no flow event is triggered.