<view-state id="enterShippingDetails" view="shippingForm">
<entry-actions>
<action bean="formAction" method="setupForm"/>
</entry-actions>
<transition on="submit" to="finish">
<action bean="formAction" method="bindAndValidate"/>
</transition>
</view-state><end-state id="finish">
<output-attribute name="shipping"/>
</end>■NoteDeciding whether to put the requiresShippingguard into the subflow or keep it in the
calling flow is an interesting exercise. On the one hand you could argue that the decision is part of the
enterShippinglogic (and hence be part of the subflow); on the other you could argue that the subflow
should only be called when needed (and hence be part of the calling flow).
When a subflow ends (by reaching an end state), the subflow signals an ending result
event with the idof the end state. The resuming subflow state in the calling flow is responsible
for executing a transition on the occurrence of that event, as well as mapping any output
attributes (which you can think of as return values).
■Tip If the flow will only ever be called as a subflow, then there is no need to specify views on the end state.
In this example the new shipping subflow is “returning” the shippingbean to the
calling flow, or at least making the shipping information available to the calling flow. The
the shippingobject once the subflow has finished. As you will see later, the calling flow
can then retrieve this and map it into its scope.
Listing 12-5 contains the definition of the shipping flow’s formActionbean.
Listing 12-5./WEB-INF/flows/shipping-flow-context.xmlBean Factory for the
shippingInformation Subflow
CHAPTER 12 ■ADVANCED SPRING WEB FLOW 339