Client Side State
At this point you might ask:
“… since the executing flow is paused when a ViewState is entered, and control is returned to the browser, how is the same flow picked up and resumed on subsequent events?”
The answer is the client tracks the unique id of the executing flow, and provides it as input when the next event is signaled. This is typically done using a hidden form field.
For example, in a jsp:
">
The “Is Passenger Info Required?” Decision State
After the user selects the Itinerary she wants, the flow has to make a contextual decision about where to go next.
Specifically, if the user has not logged in, or she has logged in but wishes to confirm her passenger information – like the credit card she will use – the flow should allow her to enter that information. On the other hand, if she has already logged in and wishes to go straight to the booking page, the flow should skip this optional step.
Basically, a dynamic decision has to be made that takes into account the user’s information and preferences.
The decision state is perfect for this. See the definition below:
The Enter Passenger Information SubFlow State
The process of managing passenger information is logically independent of the booking process. It is one part within that process, yes, but it certainly makes sense a user would want to edit her information outside of the booking context.
Subflow states facilitate this. When a subflow state is entered, a child flow is spawned. The parent flow is suspended until the child flow ends. This lets you view your application as a set of self-contained modules – flows – that you can easily embed in multiple situations in a consistent manner.
Take a look at the enterPassengerInformation subflow state:
[tr]
The flow attribute is the id of the flow to spawn when this state is entered. The attribute-mapper element maps attributes to and from the subflow. Input mappings map attributes down to the subflow. Output mappings map attributes back up to the parent flow when the subflow ends. As you can see, expressions (in this case OGNL) are also supported.
So for this business case, when the enterPassengerInformation state is entered, the passenger flow is spawned. The passengerId attribute is passed down to the flow as input. From there, the subflow does whatever it wants. It’s a black box as far the parent flow is concerned. When the subflow ends, the parent flow resumes, responding to the ending result to determine where to go next—in this case, to reservation verification.
The Display Confirmation End State
There is one last core state type that has yet to be discussed: the end state. When an end state is entered, the active flow session terminates. Upon termination, all resources associated with the flow are cleaned up for you automatically.
Below is the displayConfirmation end state that displays confirmation after an itinerary is successfully booked:
When this state is entered, the bookflight flow ends and the reservationConfirmation view displays.Because the bookflight flow was acting as the root flow, and not a subflow, it and any allocated resources are automatically cleaned up.
Note: had the ending flow been acting as a subflow, the entered end state is treated as a subflow result the resuming parent flow can respond to.More specifically, the entered end state ID is used as grounds for a state transition in the resuming parent flow's subflow state.You can see this in action by taking a look at the "enterPassengerInformation" subflow state definition.Note how it responds to the "finish" result of the subflow, which corresponds to a "finish" end state within the passenger flow
|