Results 1 to 3 of 3

Thread: errors/flashScope between parent and subflow

  1. #1
    Join Date
    Dec 2006
    Posts
    1

    Default errors/flashScope between parent and subflow

    I have recently upgraded from RC1 to 1.0, and I ran into an issue with how the errors are now stored in flash scope and a redirect is done before entering a view-state. I have a flow where errors are "stored" while in a subflow, and then execution ends the subflow and a view-state in the parent flow is entered. In the below example, the execution would be:
    parentView -> parentSubflow (myInlineFlow) -> inlineAction <error event> -> inlineErrorState -> parentView

    Code:
    <flow>
    	...
    	<view-state id="parentView" view="foo.bar"/>
    
    	<subflow-state id="parentSubflow" flow="myInlineFlow">
    		...
    		<transition on="inlineErrorState" to="parentView"/>
    	</subflow-state>
    	...
    	<inline-flow id="myInlineFlow">
                    <flow>
    			...
    			<action-state id="inlineAction">
    				...
    				<transition on="error" to="inlineErrorState"/>
    			</action-state>
    			...
    			<end-state id="inlineErrorState"/>
    		</flow>
    	</inline-flow>
    	...
    </flow>
    The errors are stored while in a method call in the inlineAction state and when the end-state is hit in the subflow, flashScope dies (which makes sense since the flash is tied to events fired in the flow). When we get to parentView for the second time, the flash (and therefore the errors) are gone. This worked in RC1 because the errors were stored in request scope, which would live even when the subflow died.

    Turning off redirect before view-state wasn't an option and neither was re-writing the flow to not have this funky relationship, nor was changing the scope of the errors. My (admittidly hacky) solution is to explicitly map the errors between the parent and subflow.

    Code:
    <flow>
    	...
    	<view-state id="parentView" view="foo.bar"/>
    
    	<subflow-state id="parentSubflow" flow="myInlineFlow">
    		<attribute-mapper>
                  		<output-mapper>
                  			<mapping source="errors" target='flashScope["org.springframework.validation.BindException.currentFormObject"]'/>
                  		</output-mapper>
                  	</attribute-mapper>
    		...
    		<transition on="inlineErrorState" to="parentView"/>
    	</subflow-state>
    	...
    	<inline-flow id="myInlineFlow">
                    <flow>
    			...
    			<action-state id="inlineAction">
    				...
    				<transition on="error" to="inlineErrorState"/>
    			</action-state>
    			...
    			<end-state id="inlineErrorState">
    				<output-mapper>
    					<mapping source='flashScope["org.springframework.validation.BindException.currentFormObject"]' target="errors"/>
    				</output-mapper>
    			</end-state>
    		</flow>
    	</inline-flow>
    	...
    </flow>

    Has anyone else ran into this problem? What was your solution? I like how my solution only required changing the flow definition, but I'm open to suggestions about the "right" way to solve this problem.

  2. #2
    Join Date
    Sep 2004
    Location
    Leuven, Belgium
    Posts
    1,853

    Default

    The errors are stored while in a method call in the inlineAction state and when the end-state is hit in the subflow, flashScope dies (which makes sense since the flash is tied to events fired in the flow).
    The idea is that flash scope dies when an new external user event is signaled in the flow, which doesn't happen in your scenario. You loose flash scope because the contents of flash scope of stored in the flow session, so you're loosing that when the subflow session ends.

    Your mapping solution seems like a relatively elegant workaround.

    Erwin

  3. #3
    Join Date
    Sep 2004
    Location
    Leuven, Belgium
    Posts
    1,853

    Default

    I've created a JIRA issue to 'think' about this:

    http://opensource.atlassian.com/proj...browse/SWF-221

    Erwin

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •