Remove remaining Portlet references

Issue: SWF-1692
This commit is contained in:
Rossen Stoyanchev
2017-01-06 11:58:05 -05:00
parent 5b0df65be4
commit 3a0857496e
25 changed files with 83 additions and 932 deletions

View File

@@ -1,12 +1,9 @@
<?xml version="1.0" encoding="UTF-8"?>
<book xml:id="spring-framework-reference"
xmlns="http://docbook.org/ns/docbook" version="5.0"
xmlns:xl="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://docbook.org/ns/docbook http://www.docbook.org/xml/5.0/xsd/docbook.xsd
http://www.w3.org/1999/xlink http://www.docbook.org/xml/5.0/xsd/xlink.xsd">
xmlns="http://docbook.org/ns/docbook" version="5.0"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://docbook.org/ns/docbook http://www.docbook.org/xml/5.0/xsd/docbook.xsd">
<info>
<title>Spring Web Flow Reference Guide</title>
@@ -96,9 +93,7 @@
<xi:include href="spring-mvc.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="spring-js.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="spring-faces.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="portlet.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="testing.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="upgrade-guide.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="flow-definition-field-mappings.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
</book>

View File

@@ -1,286 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter xml:id="portlet"
xmlns="http://docbook.org/ns/docbook" version="5.0"
xmlns:xl="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://docbook.org/ns/docbook http://www.docbook.org/xml/5.0/xsd/docbook.xsd
http://www.w3.org/1999/xlink http://www.docbook.org/xml/5.0/xsd/xlink.xsd">
<title>Portlet Integration</title>
<sect1 xml:id="portlet-introduction">
<title>Introduction</title>
<para>
This chapter shows how to use Web Flow in a Portlet environment.
Spring Web Flow requires Portlet API 2.0 to run with.
The <code>booking-portlet-mvc</code> sample application is a good reference for using Web Flow within a portlet.
This application is a simplified travel site that allows users to search for and book hotel rooms.
</para>
</sect1>
<sect1 xml:id="portlet-config-core">
<title>Configuring web.xml and portlet.xml</title>
<para>
The configuration for a portlet depends on the portlet container used.
The sample applications, included with Web Flow, are both configured to use <link xl:href="http://portals.apache.org/pluto/">Apache Pluto</link>.
</para>
<para>
In general, the configuration requires adding a servlet mapping in the <code>web.xml</code> file to dispatch request to the portlet container.
</para>
<programlisting language="xml"><![CDATA[
<servlet>
<servlet-name>swf-booking-mvc</servlet-name>
<servlet-class>org.apache.pluto.core.PortletServlet</servlet-class>
<init-param>
<param-name>portlet-name</param-name>
<param-value>swf-booking-mvc</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>swf-booking-mvc</servlet-name>
<url-pattern>/PlutoInvoker/swf-booking-mvc</url-pattern>
</servlet-mapping>
]]></programlisting>
<para>
The <code>portlet.xml</code> configuration is a standard portlet configuration.
The <code>portlet-class</code> needs to be set along with a pair of <code>init-param</code>s.
Setting the <code>expiration-cache</code> to <code>0</code> is recommended to force Web Flow to always render a fresh view.
</para>
<programlisting language="xml"><![CDATA[
<portlet>
...
<portlet-class>org.springframework.web.portlet.DispatcherPortlet</portlet-class>
<init-param>
<name>contextConfigLocation</name>
<value>/WEB-INF/web-application-config.xml</value>
</init-param>
<init-param>
<name>viewRendererUrl</name>
<value>/WEB-INF/servlet/view</value>
</init-param>
<expiration-cache>0</expiration-cache>
...
</portlet>
]]></programlisting>
</sect1>
<sect1 xml:id="portlet-config-spring">
<title>Configuring Spring</title>
<sect2 xml:id="portlet-config-spring-handler">
<title>Flow Handlers</title>
<para>
The only supported mechanism for bridging a portlet request to Web Flow is a <code>FlowHandler</code>.
The <code>PortletFlowController</code> used in Web Flow 1.0 is no longer supported.
</para>
<para>
The flow handler, similar to the servlet flow handler, provides hooks that can:
<itemizedlist>
<listitem>
<para>select the flow to execute</para>
</listitem>
<listitem>
<para>pass input parameters to the flow on initialization</para>
</listitem>
<listitem>
<para>handle the flow execution outcome</para>
</listitem>
<listitem>
<para>handle exceptions</para>
</listitem>
</itemizedlist>
</para>
<para>
The <code>AbstractFlowHandler</code> class is an implementation of <code>FlowHandler</code> that provides default implementations for these hooks.
</para>
<para>
In a portlet environment the targeted flow id can not be inferred from the URL and must be defined explicitly in the handler.
</para>
<programlisting language="java"><![CDATA[
public class ViewFlowHandler extends AbstractFlowHandler {
public String getFlowId() {
return "view";
}
}
]]></programlisting>
</sect2>
<sect2 xml:id="portlet-config-spring-mappings">
<title>Handler Mappings</title>
<para>
Spring Portlet MVC provides a rich set of methods to map portlet requests.
Complete documentation is available in the <link xl:href="http://static.springframework.org/spring/docs/current/reference/portlet.html#portlet-handlermapping">Spring Reference Documentation</link>.
</para>
<para>
The <code>booking-portlet-mvc</code> sample application uses a <code>PortletModeHandlerMapping</code> to map portlet requests.
The sample application only supports <code>view</code> mode, but support for other portlet modes is available.
Other modes can be added and point to the same flow as <code>view</code> mode, or any other flow.
</para>
<programlisting language="xml"><![CDATA[
<bean id="portletModeHandlerMapping"
class="org.springframework.web.portlet.handler.PortletModeHandlerMapping">
<property name="portletModeMap">
<map>
<entry key="view">
<bean class="org.springframework.webflow.samples.booking.ViewFlowHandler" />
</entry>
</map>
</property>
</bean>
]]></programlisting>
</sect2>
<sect2 xml:id="portlet-config-spring-handler-adapter">
<title>Flow Handler Adapter</title>
<para>
A <code>FlowHandlerAdapter</code> converts the handler mappings to the flow handlers.
The flow executor is required as a constructor argument.
</para>
<programlisting language="xml"><![CDATA[
<bean id="flowHandlerAdapter"
class="org.springframework.webflow.mvc.portlet.FlowHandlerAdapter">
<property name="flowExecutor" ref="flowExecutor" />
</bean>
]]></programlisting>
</sect2>
</sect1>
<sect1 xml:id="portlet-views">
<title>Portlet Views</title>
<para>
In order to facilitate view rendering, a <code>ViewRendererServlet</code> must be added to the <code>web.xml</code> file.
This servlet is not invoked directly, but it used by Web Flow to render views in a portlet environment.
</para>
<programlisting language="xml"><![CDATA[
<servlet>
<servlet-name>ViewRendererServlet</servlet-name>
<servlet-class>org.springframework.web.servlet.ViewRendererServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>ViewRendererServlet</servlet-name>
<url-pattern>/WEB-INF/servlet/view</url-pattern>
</servlet-mapping>
]]></programlisting>
</sect1>
<sect1 xml:id="portlet-modes">
<title>Portlet Modes and Window States</title>
<sect2 xml:id="portlet-modes-state">
<title>Window State</title>
<para>
The Portlet API defined three window states: normal, minimized and maximized.
The portlet implementation must decide what to render for each of these window states.
Web Flow exposes the string value of the window state under <code>portletWindowState</code> via the request map on the external context.
</para>
<programlisting language="java"><![CDATA[
requestContext.getExternalContext().getRequestMap().get("portletWindowState");
]]></programlisting>
<programlisting><![CDATA[
externalContext.requestMap.portletWindowState
]]></programlisting>
</sect2>
<sect2 xml:id="portlet-modes-mode">
<title>Portlet Mode</title>
<para>
The Portlet API defined three portlet modes: view, edit and help.
The portlet implementation must decide what to render for each of these modes.
Web Flow exposes the string value of the portlet mode under <code>portletMode</code> via the request map on the external context.
</para>
<programlisting language="java"><![CDATA[
requestContext.getExternalContext().getRequestMap().get("portletMode");
]]></programlisting>
<programlisting><![CDATA[
externalContext.requestMap.portletMode
]]></programlisting>
</sect2>
</sect1>
<sect1 xml:id="portlet-jsf">
<title>Using Portlets with JSF</title>
<sect2 xml:id="portlet-jsf-using-portlet-jsf">
<para>
Prior to version 2.1 of Spring Web Flow, support for JSF Portlets was considered
experimental and relied on a Portlet Bridge for JSF implementation.
Furthermore JSR-329 (the latest specification in this area), which targets
Portlet API 2.0 and JSF 1.2 environments at the time of writing is not yet
final causing portlet bridge implementations to also remain incomplete.
</para>
<para>
A closer comparison of Spring Web Flow and a Portlet Bridge for JSF shows
the two have significant overlap. They both drive the
JSF lifecycle and they both shield JSF from knowledge about Portlet action
and render requests.
</para>
<para>
Considering all of the above, starting with version 2.2, Spring Web Flow
provides support for JSF Portlets using its own internal Portlet integration rather
than a Portlet Bridge for JSF. We believe this will provide value for Web Flow users
by reducing the number of dependencies in what is already a fairly complex
combination of technologies with specifications lagging behind.
</para>
<para>
What this practically means is the configuration required for JSF Portlets is
very similar to what is alread documented in the rest of this chapter
with the exception of <xref linkend="portlet-views"/>, which is not necessary
with JSF.
</para>
<para>
Review the <code>swf-booking-portlet-faces</code> sample in the Web Flow distribution
for a working JSF Portlets example with complete configuration details. The main
things to ensure are that the <code>&lt;faces:resources&gt;</code> elements is
included as part of your Spring configuration and that your
<code>faces-config.xml</code> configuration includes a <code>PortletViewHandler</code>:
</para>
<programlisting language="java"><![CDATA[<?xml version="1.0"?>
<!DOCTYPE faces-config PUBLIC
"-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
"http://java.sun.com/dtd/web-facesconfig_1_0.dtd">
<faces-config>
<application>
<view-handler>
org.springframework.faces.webflow.context.portlet.PortletViewHandler
</view-handler>
</application>
</faces-config>
]]></programlisting>
<para>
The JSF Portlet support provided with Spring Web Flow requires JSF v2.0 or above. If
you are upgrading from a previous release you should ensure that your <code>faces-config.xml</code>
references <code>org.springframework.faces.webflow.context.portlet.PortletViewHandler</code> instead
of <code>org.springframework.faces.webflow.application.portlet.PortletFaceletViewHandler</code>. You
should also ensure that you have added <code>&lt;faces:resources&gt;</code> to you Spring configuration.
</para>
<para>
Although JSF v2.0 is a minimum requirement, this has been primarily driven to provide better support in
a Servlet environment. Many of the more advanced JSF 2.0 features (for example 'Partial State Saving')
are not supported by Spring Web Flow in a Portlet environment.
</para>
</sect2>
</sect1>
<sect1 xml:id="portlet-issues">
<title>Issues in a Portlet Environment</title>
<sect2 xml:id="portlet-issues-redirects">
<title>Redirects</title>
<para>
The Portlet API only allows redirects to be requested from an action request.
Because views are rendered on the render request, views and <code>view-state</code>s cannot trigger a redirect.
</para>
<para>
The <code>externalRedirect:</code> view prefix is a convenience for Servlet based flows.
An <code>IllegalStateException</code> is thrown if a redirect is requested from a render request.
</para>
<para>
<code>end-state</code> redirects can be achieved by implementing <code>FlowHandler.handleExecutionOutcome</code>.
This callback provides the <code>ActionResponse</code> object which supports redirects.
</para>
</sect2>
<sect2 xml:id="portlet-issues-modes">
<title>Switching Portlet Modes</title>
<para>
The portlet container passes the execution key from the previous flow when switching to a new mode.
Even if the mode is mapped to a different <code>FlowHandler</code> the flow execution will resume the previous execution.
You may switch the mode programatically in your FlowHandler after ending a flow in an ActionRequest.
</para>
<para>
One way to start a new flow is to create a URL targeting the mode without the execution key.
</para>
</sect2>
</sect1>
</chapter>

View File

@@ -23,10 +23,6 @@ xsi:schemaLocation="
JSF v2.0 or above. Both Sun Mojarra and Apache MyFaces runtime environments
are supported.</para>
<para>Spring Web Flow also supports using JSF in a portlet environment.
Spring Web Flow's portlet integration supports Portlets API 2.0.
See <xref linkend="portlet" /> for more on Spring Web Flow's portlet
integration.</para>
</sect1>
<sect1 xml:id="spring-faces-integration">

View File

@@ -1,278 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter xml:id="upgrade-guide"
xmlns="http://docbook.org/ns/docbook" version="5.0"
xmlns:xl="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://docbook.org/ns/docbook http://www.docbook.org/xml/5.0/xsd/docbook.xsd
http://www.w3.org/1999/xlink http://www.docbook.org/xml/5.0/xsd/xlink.xsd">
<title>Upgrading from 1.0</title>
<sect1 xml:id="upgrade-guide-introduction">
<title>Introduction</title>
<para>
This chapter shows you how to upgrade existing Web Flow 1 application to Web Flow 2.
</para>
</sect1>
<sect1 xml:id="upgrade-guide-definition-language">
<title>Flow Definition Language</title>
<para>
The core concepts behind the flow definition language have not changed between Web Flow 1 and 2.
However, some of the element and attribute names have changed.
These changes allow for the language to be both more concise and expressive.
A complete list of <link linkend="field-mappings">mapping changes</link> is available as an appendix.
</para>
<sect2 xml:id="upgrade-guide-definition-language-tool">
<title>Flow Definition Updater Tool</title>
<para>
An automated tool is available to aid in the conversion of existing 1.x flows to the new 2.x style.
The tool will convert all the old tag names to their new equivalents, if needed.
While the tool will make a best effort attempt at conversion, there is not a one-to-one mapping for all version 1 concepts.
If the tool was unable to convert a portion of the flow, it will be marked with a <code>WARNING</code> comment in the resulting flow.
</para>
<para>
The conversion tool requires spring-webflow.jar, spring-core.jar and an XSLT 1.0 engine.
<link xl:href="http://saxon.sourceforge.net/">Saxon 6.5.5</link> is recommended.
</para>
<para>
The tool can be run from the command line with the following command.
Required libraries must be available on the classpath.
The source must be a single flow to convert.
The resulting converted flow will be sent to standard output.
</para>
<programlisting>
java org.springframework.webflow.upgrade.WebFlowUpgrader flow-to-upgrade.xml
</programlisting>
<sect3 xml:id="upgrade-guide-definition-language-tool-warnings">
<title>Flow Definition Updater Tool Warnings</title>
<sect4 xml:id="upgrade-guide-definition-language-tool-warnings-argument-parameter-type">
<title>argument parameter-type no longer supported</title>
<para>
Bean actions have been deprecated in favor of EL based evaluate expressions.
The EL expression is able to accept method parameters directly, so there is no longer a need for the argument tag.
A side effect of this change is that method arguments must be of the correct type before invoking the action.
</para>
</sect4>
<sect4 xml:id="upgrade-guide-definition-language-tool-warnings-inline-flow">
<title>inline-flow is no longer supported</title>
<para>
Inline flows are no longer supported.
The contents of the inline flow must be moved into a new top-level flow.
The inline flow's content has been converted for your convenience.
</para>
</sect4>
<sect4 xml:id="upgrade-guide-definition-language-tool-warnings-mapping-target-collection">
<title>mapping target-collection is no longer supported</title>
<para>
Output mappings can no longer add an item to a collection.
Only assignment is supported.
</para>
</sect4>
<sect4 xml:id="upgrade-guide-definition-language-tool-warnings-var-bean">
<title>var bean is no longer supported</title>
<para>
The var bean attribute is no longer needed.
All spring beans can be resolved via EL.
</para>
</sect4>
<sect4 xml:id="upgrade-guide-definition-language-tool-warnings-var-scope">
<title>var scope is no longer supported</title>
<para>
The var element will place all variable into flow scope.
Conversation scope was previously allowed.
</para>
</sect4>
</sect3>
</sect2>
<sect2 xml:id="upgrade-guide-definition-language-el">
<title>EL Expressions</title>
<para>
EL expressions are used heavily throughout the flow definition language.
Many of the attributes that appear to be plain text are actually interpreted as EL.
The standard EL delimiters (either ${} or #{} in Web Flow 2.0 or just #{} in Web Flow 2.1) are not necessary and will often cause an exception if they are included.
</para>
<para>
EL delimiters should be removed where necessary by the updater tool.
</para>
</sect2>
</sect1>
<sect1 xml:id="upgrade-guide-webflow-config">
<title>Web Flow Configuration</title>
<para>
In Web Flow 1 there were two options available for configuring Web Flow, one using standard spring bean XML and the other using the <code>webflow-config-1.0</code> schema.
The schema configuration option simplifies the configuration process by keeping long internal class names hidden and enabling contextual auto-complete.
The schema configuration option is the only way to configure Web Flow 2.
</para>
<sect2 xml:id="upgrade-guide-webflow-config-beans">
<title>Web Flow Bean Configuration</title>
<para>
The <code>FactoryBean</code> bean XML configuration method used in Web Flow 1 is no longer supported.
The schema configuration method should be used instead.
In particular beans defining <code>FlowExecutorFactoryBean</code> and <code>XmlFlowRegistryFactoryBean</code> should be updated.
Continue reading Web Flow Schema Configuration for details.
</para>
</sect2>
<sect2 xml:id="upgrade-guide-webflow-config-schema">
<title>Web Flow Schema Configuration</title>
<para>
The <code>webflow-config</code> configuration schema has also changed slightly from version 1 to 2.
The simplest way to update your application is modify the version of the schema to 2.0 then fix any errors in a schema aware XML editor.
The most common change is add 'flow-' to the beginning of the elements defined by the schema.
</para>
<programlisting language="xml"><![CDATA[
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:webflow="http://www.springframework.org/schema/webflow-config"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.0.xsd
http://www.springframework.org/schema/webflow-config
http://www.springframework.org/schema/webflow-config/spring-webflow-config-2.4.xsd">
]]></programlisting>
<sect3 xml:id="upgrade-guide-webflow-config-schema-executor">
<title>flow-executor</title>
<para>
The flow executor is the core Web Flow configuration element.
This element replaces previous <code>FlowExecutorFactoryBean</code> bean definitions.
</para>
<programlisting language="xml"><![CDATA[
<webflow:flow-executor id="flowExecutor" />
]]></programlisting>
</sect3>
<sect3 xml:id="upgrade-guide-webflow-config-schema-listeners">
<title>flow-execution-listeners</title>
<para>
Flow execution listeners are also defined in the flow executor.
Listeners are defined using standard bean definitions and added by reference.
</para>
<programlisting language="xml"><![CDATA[
<webflow:flow-executor id="flowExecutor" flow-registry="flowRegistry">
<webflow:flow-execution-listeners>
<webflow:listener ref="securityFlowExecutionListener"/>
</webflow:flow-execution-listeners>
</webflow:flow-executor>
<bean id="securityFlowExecutionListener"
class="org.springframework.webflow.security.SecurityFlowExecutionListener" />
]]></programlisting>
</sect3>
<sect3 xml:id="upgrade-guide-webflow-config-schema-registry">
<title>flow-registry</title>
<para>
The <code>flow-registry</code> contains a set of <code>flow-location</code>s.
Every flow definition used by Web Flow must be added to the registry.
This element replaces previous <code>XmlFlowRegistryFactoryBean</code> bean definitions.
</para>
<programlisting language="xml"><![CDATA[
<webflow:flow-registry id="flowRegistry">
<webflow:flow-location path="/WEB-INF/hotels/booking/booking.xml" />
</webflow:flow-registry>
]]></programlisting>
</sect3>
</sect2>
<sect2 xml:id="upgrade-guide-java-controller">
<title>Flow Controller</title>
<para>
The package name for flow controllers has changed from <code>org.springframework.webflow.executor.mvc.FlowController</code> and is now <code>org.springframework.webflow.mvc.servlet.FlowController</code> for Servlet MVC requests.
The portlet flow controller <code>org.springframework.webflow.executor.mvc.PortletFlowController</code> has been replaced by a flow handler adapter available at <code>org.springframework.webflow.mvc.portlet.FlowHandlerAdapter</code>.
They will need to be updated in the bean definitions.
</para>
</sect2>
<sect2 xml:id="upgrade-guide-java-url-handler">
<title>Flow URL Handler</title>
<para>
The default URL handler has changed in Web Flow 2.
The flow identifier is now derived from the URL rather then passed explicitly.
In order to maintain comparability with existing views and URL structures a <code>WebFlow1FlowUrlHandler</code> is available.
</para>
<programlisting language="xml"><![CDATA[
<bean name="/pos.htm" class="org.springframework.webflow.mvc.servlet.FlowController">
<property name="flowExecutor" ref="flowExecutor" />
<property name="flowUrlHandler">
<bean class="org.springframework.webflow.context.servlet.WebFlow1FlowUrlHandler" />
</property>
</bean>
]]></programlisting>
</sect2>
<sect2 xml:id="upgrade-guide-webflow-config-view-resolver">
<title>View Resolution</title>
<para>
Web Flow 2 by default will both select and render views.
View were previously selected by Web Flow 1 and then rendered by an external view resolver.
</para>
<para>
In order for version 1 flows to work in Web Flow 2 the default view resolver must be overridden.
A common use case is to use <link xl:href="http://tiles.apache.org/">Apache Tiles</link> for view resolution.
The following configuration will replace the default view resolver with a Tiles view resolver.
The <code>tilesViewResolver</code> in this example can be replaced with any other view resolver.
</para>
<programlisting language="xml"><![CDATA[
<webflow:flow-registry id="flowRegistry" flow-builder-services="flowBuilderServices">
<web:flow-location path="..." />
...
</webflow:flow-registry>
<webflow:flow-builder-services id="flowBuilderServices"
view-factory-creator="viewFactoryCreator"/>
<bean id="viewFactoryCreator" class="org.springframework.webflow.mvc.builder.MvcViewFactoryCreator">
<property name="viewResolvers" ref="tilesViewResolver" />
</bean>
<bean id="tilesViewResolver" class="org.springframework.web.servlet.view.UrlBasedViewResolver">
<property name="viewClass" value="org.springframework.web.servlet.view.tiles.TilesJstlView" />
</bean>
<bean class="org.springframework.web.servlet.view.tiles.TilesConfigurer">
<property name="definitions" value="/WEB-INF/tiles-def.xml" />
</bean>
]]></programlisting>
</sect2>
</sect1>
<sect1 xml:id="upgrade-guide-webflow-concepts">
<title>New Web Flow Concepts</title>
<sect2 xml:id="upgrade-guide-webflow-concepts-binding">
<title>Automatic Model Binding</title>
<para>
Web Flow 1 required Spring MVC based flows to manually call <code>FormAction</code> methods, notably:
<code>setupForm</code>, <code>bindAndValidate</code> to process form views.
Web Flow 2 now provides automatic model setup and binding using the <code>model</code> attribute for <code>view-state</code>s.
Please see the <link linkend="view-model">Binding to a Model</link> section for details.
</para>
</sect2>
<sect2 xml:id="upgrade-guide-webflow-concepts-el-v-ognl">
<title>OGNL vs Spring EL</title>
<para>
Web Flow 1 used OGNL exclusively for expressions within the flow definitions.
Web Flow 2 adds support for Unified EL.
Web Flow 2.1 uses Spring EL by default.
United EL and OGNL can still be plugged in.
Please see <xref linkend="el"/> for details.
</para>
</sect2>
<sect2 xml:id="upgrade-guide-webflow-concepts-flash-scope">
<title>Flash Scope</title>
<para>
Flash scope in Web Flow 1 lived across the current request and into the next request.
This was conceptually similar to Web Flow 2's view scope concept, but the semantics were not as well defined.
In Web Flow 2, flash scope is cleared after every view render.
This makes flashScope semantics in Web Flow consistent with other web frameworks.
</para>
</sect2>
<sect2 xml:id="upgrade-guide-webflow-concepts-jsf">
<title>JSF</title>
<para>
Web Flow 2 offers significantly improved integration with JSF.
Please see <xref linkend="spring-faces"/> for details.
</para>
</sect2>
<sect2 xml:id="upgrade-guide-webflow-concepts-redirects">
<title>External Redirects</title>
<para>
External redirects in Web Flow 1 were always considered context relative.
In Web Flow 2, if the redirect URL begins with a slash, it is considered servlet-relative instead of context-relative.
URLs without a leading slash are still context relative.
</para>
</sect2>
</sect1>
</chapter>

View File

@@ -77,9 +77,6 @@
Upgraded projects will need to ensure that the <code>&lt;faces:resources&gt;</code> elements is
included as part of their Spring configuration.
</para>
<para>
See <xref linkend="portlet-jsf"/>.
</para>
</sect2>
<sect2 xml:id="whatsnew-deprecation">
<title>Deprecations</title>
@@ -97,83 +94,4 @@
</para>
</sect2>
</sect1>
<sect1 xml:id="whatsnew-swf-230">
<title>Spring Web Flow 2.3</title>
<sect2 xml:id="whatsnew-swf-embedded-flow">
<title>Embedding A Flow On A Page</title>
<para>
By default Web Flow does a client-side redirect upon entering every view state.
That makes it impossible to embed a flow on a page or within a modal dialog and execute more than one view state without causing a full-page refresh.
Web Flow now supports launching a flow in "embedded" mode.
In this mode a flow can transition to other view states without a client-side redirect during Ajax requests.
See <xref linkend="spring-mvc-embedded-flow"/> and <xref linkend="spring-faces-embedded-mode"/>.
</para>
</sect2>
<sect2 xml:id="whatsnew-jsr303">
<title>Support For JSR-303 Bean Validation</title>
<para>
Support for the JSR-303 Bean Validation API is now available building on equivalent support available in Spring MVC.
See <xref linkend="view-validate"/> for more details.
</para>
</sect2>
<sect2 xml:id="whatsnew-pc-propagation">
<title>Flow-Managed Persistence Context Propagation</title>
<para>
Starting with Web Flow 2.3 a flow managed <code>PersistenceContext</code> is automatically extended (propagated) to sub-flows assuming the subflow also has the feature enabled as well.
See <xref linkend="flow-managed-persistence-propagation"/>.
</para>
</sect2>
<sect2 xml:id="whatsnew-portlet-resource-requests">
<title>Portlet 2.0 Resource Requests</title>
<para>
Support for Portlet 2.0 resource requests has now been added enabling Ajax requests with partial rendering.
URLs for such requests can be prepared with the <code>&lt;portlet:resourceURL&gt;</code> tag in JSP pages.
Server-side processing is similar to a combined an action and a render requests but combined in a single request.
Unlike a render request, the response from a resource request includes content from the target portlet only.
</para>
</sect2>
<sect2 xml:id="whatsnew-conversation-manager">
<title>Custom ConversationManager</title>
<para>
The <code>&lt;flow-execution-repository&gt;</code> element now provides a conversation-manager attribute accepting a reference to a ConversationManager instance.
</para>
</sect2>
<sect2 xml:id="whatsnew-redirect-in-same-state">
<title>Redirect In Same State</title>
<para>
By default Web Flow does a client-side redirect when remaining in the same view state as long as the current request is not an Ajax request.
This is useful after form validation failure.
Hitting Refresh or Back won't result in browser warnings.
Hence this behavior is usually desirable.
However a new flow execution attribute makes it possible to disable it and that may also be necessary in some cases specific to JSF applications.
See <xref linkend="spring-faces-redirect-in-same-state"/>.
</para>
</sect2>
<sect2 xml:id="whatsnew-samples">
<title>Samples</title>
<para>
The process for building the samples included with the distribution has been simplified.
Maven can be used to build all samples in one step.
Eclipse settings include source code references to simplify debugging.
</para>
<para>
Additional samples can be accessed as follows:
<programlisting language="xml">mkdir spring-samples
cd spring-samples
svn co https://src.springframework.org/svn/spring-samples/webflow-primefaces-showcase
cd webflow-primefaces-showcase
mvn package
# import into Eclipse
</programlisting>
<programlisting language="xml">mkdir spring-samples
cd spring-samples
svn co https://src.springframework.org/svn/spring-samples/webflow-showcase
cd webflow-showcase
mvn package
# import into Eclipse
</programlisting>
</para>
</sect2>
</sect1>
</chapter>