The view can submit the eventIdin one of two ways. The first way is to submit a request para-
meter whose name is FlowExecutionManagerParameterExtractor.getEventIdParameterName()
(the default is _eventId) and whose valuewill be the actual user eventId (like submit).
■NoteFor the sake of brevity and readability,FlowExecutionManagerParameterExtractormay be
referred to as FEMPE.
Alternatively, the second way is to have the view submit a parameter whose name has the
format FEMPE.getEventIdParameterName()FEMPE.getParameterDelimiter()value(the default
value for FEMPE.getParameterDelimiter()is “_”). This form is primarily used with the name of
an HTML input button to support multiple buttons per form without JavaScript. In this case,
the eventIdis derived fully from the parameter name, and the value of this parameter is
ignored.
To illustrate these two approaches, to signal the submit event you may provide either of
the following request parameters: _eventId=submitor _eventId_submit=ignored.
■NoteFlowExecutionManagerParameterExtractorwill also support image buttons that submit
parameters of type eventId.xor eventId.y.
Decision States
Although the example decision state in Chapter 11 defined a simple, single if/else expression,
decision states can do more. As well as supporting multipleifconditions, the decision state
can also delegate the criteria for the decision to Java application code.
If multiple ifconditions are supplied, they are evaluated one by one. If none of the condi-
tions evaluates to true, then a NoMatchingTransitionExceptionis thrown. You can implement
a chain of if conditions, but realize that any ifcondition that defines an elseclause will by
definitionevaluate to true, and none of the remaining ifconditions will be evaluated. For
example, the fragment in Listing 12-26 will never evaluate the second condition.
Listing 12-26.Badly Defined Decision State
Listing 12-27 shows a chain of conditions that behaves as you would expect.CHAPTER 12 ■ADVANCED SPRING WEB FLOW 365