Spring/spring-webflow
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fixed SWF-435.

Browse Source
This commit is contained in:
Erwin Vervaet
2008-09-05 19:29:28 +00:00
parent 3a2d88f2fa
commit 8be104c4e1
2 changed files with 8 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
spring-webflow/changelog.txt
View File

@@ -21,6 +21,7 @@ Package org.springframework.webflow.executor
the flow execution (SWF-745).
* FlowPhaseListener will now save the JSF component state before a flow execution redirect is issued (SWF-747).
* Fixed FlowPhaseListener to correctly deal with scenarios where we fallback to standard JSF navigation.
* Fixed use of wrong flow execution key in externalRedirect view when using PortletFlowController (SWF-435).
Changes in version 1.0.5 (03.10.2007)
-------------------------------------
@@ -969,7 +970,7 @@ Changes in version PR3 (22.5.2005)
* Pluggable expression evaluation capability.
* Pluggability for all core definition objects: Flow, State, Transition, action, ...
* Pluggability of transaction synchronizer interface for custom application-transaction demarcation.
* A lot of general refining and polishing <20> package structure should be stable now.
* A lot of general refining and polishing <20> package structure should be stable now.
* Flow attribute mapping is now possible from a XML definition using the new "input", and "output" mapping elements within the
"attribute-mapper" element (see the spring-webflow.dtd).
* FlowController now provides a setFlow(Flow) method for convenience.

12
spring-webflow/src/main/java/org/springframework/webflow/executor/mvc/PortletFlowController.java
View File

@@ -60,12 +60,11 @@ import org.springframework.webflow.executor.support.ResponseInstructionHandler;
* result from technical limitations in the Portlet API, for instance the fact that a render request cannot issue a
* redirect. Keep the following in mind when developing Portlets using Spring Web Flow:
* <ul>
* <li>Using the well known POST-REDIRECT-GET idiom, for instance using <i>alwaysRedirectOnPause</i> or the
* "redirect:" view prefix, does not make sense in a Portlet environment where the Portlet container handles this using
* a seperate <i>render phase</i>. In other words, a {@link FlowExecutionRedirect} is not supportd.</li>
* <li>Using the well known POST-REDIRECT-GET idiom, for instance using <i>alwaysRedirectOnPause</i> or the "redirect:"
* view prefix, does not make sense in a Portlet environment where the Portlet container handles this using a seperate
* <i>render phase</i>. In other words, a {@link FlowExecutionRedirect} is not supportd.</li>
* <li>This controller will launch a new flow execution <i>every time</i> it handles a render request without having
* previously handled an action request (for the same session) or the render request containing a flow execution key.
* </li>
* previously handled an action request (for the same session) or the render request containing a flow execution key.</li>
* <li>Launching new flow executions is done in the render phase. As a result the first view selection your flow makes
* cannot be a {@link FlowDefinitionRedirect} or an {@link ExternalRedirect}.</li>
* </ul>
@@ -224,7 +223,8 @@ public class PortletFlowController extends AbstractController implements Initial
protected void handleExternalRedirect(ExternalRedirect redirect) throws Exception {
// issue the redirect to the external URL
String url = argumentHandler.createExternalUrl(redirect, flowExecutionKey, context);
String url = argumentHandler.createExternalUrl(redirect, responseInstruction.getFlowExecutionKey(),
context);
response.sendRedirect(url);
}