|
From: Erwin V. <erw...@er...> - 2005-08-06 18:28:54
|
> I noticed the parent request scope is empty when a sub flow > terminates. Why is this, it makes sense to keep it. I'm not sure what you're hinting at here, but the request scope is shared between parent en sub flow. It is scoped for the lifetime of the request, so when a subflow-state passes a request from the parent to a subflow the request scope remains unchanged. The same is true when an end-state moves the request from an ending subflow back up to the parent flow. > If I want to select an entity from a form I submit the entire for to a > form action. Next I start a sub flow to do the selection and the > output part of the flow attribute mapper gets the command object from > the request and binds the selected entity to the command object. Yes, that seems normal practice so far. > But since the request is empty after the sub flow completion I have to > put the form action in flow scope and put the command object in the > request scope myself after the sub flow completes so that the form > view in the parent flow renders propertly. ??? Yes you'll have to put the form object in flow scope of the parent flow since you want it to stick around for use when the subflow returns (i.e. you want to map the selected entity into one of its properties in the subflow output mapper). Why would you have to put the command object in the request scope to get the view to render properly? The merged content of request and flow scope is exposed to the view in the model, so it should not matter where the command object is. > Keeping the request scope intact would be easier. As I said, the request scope remains untouched when moving between parent and subflows, so I don't really see the problem... Erwin |