fixes for known 2.0.0 bugs reported since release - see changelog
This commit is contained in:
@@ -85,13 +85,15 @@
|
||||
<sect1 id="conversationScopedPersistenceContext">
|
||||
<title>ConversationScoped PersistenceContext</title>
|
||||
<para>
|
||||
This pattern creates a <code>PersistenceContext</code> in <code>conversationScope</code> on flow startup,
|
||||
and uses that context for data access until the conversation ends.
|
||||
This pattern creates a <code>PersistenceContext</code> in <code>conversationScope</code> on flow startup, and uses that context for data access until the conversation ends.
|
||||
This pattern generally employs a manual flush mode; that is, the application decides when to flush changes to the database.
|
||||
A convention for flow-managed flushing may be employed, such as always flushing after a transition one from one view-state to another.
|
||||
This pattern provides no flow-level isolation of intermediate edits since flushing synchronizes persistent object state with the database.
|
||||
With this pattern, all data access generally occurs non-transactionally.
|
||||
</para>
|
||||
<para>
|
||||
An implementation of this flow-managed persistence pattern is not yet available in the Web Flow distribution, and will be considered for future releases.
|
||||
</para>
|
||||
</sect1>
|
||||
<sect1 id="viewScopedPersistenceContext">
|
||||
<title>ViewState PersistenceContext</title>
|
||||
@@ -104,5 +106,8 @@
|
||||
This pattern is often used in conjunction with an optimistic locking strategy to protect the integrity of data modified in parallel by multiple users.
|
||||
This pattern stores much less flow state, but generally increases the amount of data access since persistent entities are fetched and flushed more often.
|
||||
</para>
|
||||
<para>
|
||||
An implementation of this flow-managed persistence pattern is not yet available in the Web Flow distribution, and will be considered for future releases.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
@@ -181,6 +181,32 @@ public class BookingFlowHandler extends AbstractFlowHandler {
|
||||
]]>
|
||||
</programlisting>
|
||||
</sect2>
|
||||
<sect2 id="spring-mvc-flow-handler-redirects">
|
||||
<title>FlowHandler Redirects</title>
|
||||
<para>
|
||||
A FlowHandler handling a FlowExecutionOutcome or FlowException returns a <code>String</code> to indicate the resource to redirect to after handling.
|
||||
In the previous example, the <code>BookingFlowHandler</code> redirects to the <code>booking/show</code> resource URI for <code>bookingConfirmed</code> outcomes,
|
||||
and the <code>hotels/index</code> resource URI for all other outcomes.
|
||||
</para>
|
||||
<para>
|
||||
By default, returned resource locations are relative to the current servlet mapping.
|
||||
This allows for a flow handler to redirect to other Controllers in the application using relative paths.
|
||||
In addition, explicit redirect prefixes are supported for cases where more control is needed.
|
||||
</para>
|
||||
<para>
|
||||
The explicit redirect prefixes supported are:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem><para><code>servletRelative:</code> - redirect to a resource relative to the current servlet</para></listitem>
|
||||
<listitem><para><code>contextRelative:</code> - redirect to a resource relative to the current web application context path</para></listitem>
|
||||
<listitem><para><code>serverRelative:</code> - redirect to a resource relative to the server root</para></listitem>
|
||||
<listitem><para><code>http://</code> or <code>https://</code> - redirect to a fully-qualified resource URI</para></listitem>
|
||||
</itemizedlist>
|
||||
<para>
|
||||
These same redirect prefixes are also supported within a flow definition when using the <code>externalRedirect:</code> directive in
|
||||
conjunction with a view-state or end-state; for example, <code>view="externalRedirect:http://springframework.org"</code>
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1 id="spring-mvc-config-spring-flow-controllers">
|
||||
<title>Flow Controller</title>
|
||||
|
||||
@@ -161,11 +161,6 @@
|
||||
For a flow event to be generated that can drive a view state transition, model binding must complete successfully.
|
||||
If model binding fails, the view is re-rendered to allow the user to revise their edits.
|
||||
</para>
|
||||
<para>
|
||||
The exact model binding and validation semantics are a function of the view technology in use.
|
||||
See the Spring MVC and Faces section for more information on MVC and JSF semantics, respectively.
|
||||
Regardless of the view technology used, your flow should not change.
|
||||
</para>
|
||||
</sect1>
|
||||
<sect1 id="view-bind">
|
||||
<title>Suppressing binding</title>
|
||||
|
||||
Reference in New Issue
Block a user