fixes for known 2.0.0 bugs reported since release - see changelog

This commit is contained in:
Keith Donald
2008-05-06 07:05:18 +00:00
parent c9179d9d21
commit 797e203f8f
54 changed files with 840 additions and 397 deletions

View File

@@ -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>

View File

@@ -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>

View File

@@ -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>