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.