fixed doc errors
This commit is contained in:
@@ -6,7 +6,7 @@
|
||||
<para>
|
||||
This chapter begins the Users Section.
|
||||
It shows how to implement flows using the flow definition language.
|
||||
By the end of this chapter, you should have a good understanding of language constructs and capable of authoring a flow definition.
|
||||
By the end of this chapter you should have a good understanding of language constructs, and be capable of authoring a flow definition.
|
||||
</para>
|
||||
</sect1>
|
||||
<sect1 id="flow-overview">
|
||||
@@ -173,7 +173,7 @@
|
||||
<sect2 id="evaluate-element">
|
||||
<title>evaluate</title>
|
||||
<para>
|
||||
The action element you will use the most often is the <code>evaluate</code> element.
|
||||
The action element you will use most often is the <code>evaluate</code> element.
|
||||
Use the <code>evaluate</code> element to evaluate an expression at a point within your flow.
|
||||
With this single tag you can invoke methods on Spring beans or any other flow variable.
|
||||
For example:
|
||||
@@ -263,7 +263,7 @@ public interface FlowOutcome {
|
||||
<sect2 id="input-element">
|
||||
<title>input</title>
|
||||
<para>
|
||||
Use the input element to declare a flow input attribute:
|
||||
Use the <code>input</code> element to declare a flow input attribute:
|
||||
</para>
|
||||
<programlisting language="xml"><![CDATA[
|
||||
<input name="hotelId" />]]>
|
||||
@@ -296,7 +296,7 @@ public interface FlowOutcome {
|
||||
</sect3>
|
||||
<sect3 id="input-element-required">
|
||||
<para>
|
||||
Use the required attribute to enforce the input is not null or empty:
|
||||
Use the <code>required</code> attribute to enforce the input is not null or empty:
|
||||
</para>
|
||||
<programlisting language="xml"><![CDATA[
|
||||
<input name="hotelId" type="long" value="flowScope.hotelId" required="true" />]]>
|
||||
@@ -374,7 +374,7 @@ public interface FlowOutcome {
|
||||
<para>
|
||||
A flow may declare one or more instance variables.
|
||||
These variables are allocated when the flow starts.
|
||||
Any @Autowired transient references the variable holds are also rewired when the flow resumes.
|
||||
Any <code>@Autowired</code> transient references the variable holds are also rewired when the flow resumes.
|
||||
</para>
|
||||
<sect2 id="var-element">
|
||||
<title>var</title>
|
||||
@@ -414,7 +414,7 @@ public interface FlowOutcome {
|
||||
<sect3 id="subflow-state-element-input">
|
||||
<title>Passing a subflow input</title>
|
||||
<para>
|
||||
Use the input element to pass input to the subflow:
|
||||
Use the <code>input</code> element to pass input to the subflow:
|
||||
</para>
|
||||
<programlisting language="xml"><![CDATA[
|
||||
<subflow-state id="addGuest" subflow="createGuest">
|
||||
|
||||
@@ -17,7 +17,7 @@
|
||||
<code>jboss-el</code> is currently the default EL implementation.
|
||||
When found in your classpath along with the <code>el-api</code>, it will be used automatically.
|
||||
<note>
|
||||
The <code>el-api</code> dependency is typically a <emphasis>provided</emphasis> by your web container. Tomcat 6 includes it, for example.
|
||||
The <code>el-api</code> dependency is typically <emphasis>provided</emphasis> by your web container. Tomcat 6 includes it, for example.
|
||||
</note>
|
||||
</para>
|
||||
</sect2>
|
||||
@@ -61,7 +61,7 @@
|
||||
<sect3 id="el-types-eval">
|
||||
<title>Standard eval expressions</title>
|
||||
<para>
|
||||
The first, and most common type of expression, is the standard <emphasis>eval expression</emphasis>.
|
||||
The first, and most common, type of expression, is the standard <emphasis>eval expression</emphasis>.
|
||||
Such expressions are dynamically evaluated by the EL and should not be enclosed in delimiters like <code>${}</code> or <code>#{}</code>.
|
||||
For example:
|
||||
</para>
|
||||
|
||||
@@ -64,7 +64,7 @@
|
||||
<title>Abstract flows</title>
|
||||
<para>
|
||||
Often parent flows are not designed to be executed directly.
|
||||
In order to protect these flow from running, they can be marked as <code>abstract</code>.
|
||||
In order to protect these flows from running, they can be marked as <code>abstract</code>.
|
||||
If an abstract flow attempts to run, a <code>FlowBuilderException</code> will be thrown.
|
||||
</para>
|
||||
<programlisting language="xml"><![CDATA[
|
||||
@@ -78,7 +78,7 @@
|
||||
There are rules for every element in the Web Flow definition language that govern how that particular element is merged.
|
||||
</para>
|
||||
<para>
|
||||
There are two types of elements mergeable and non-mergeable.
|
||||
There are two types of elements: <emphasis>mergeable</emphasis> and <emphasis>non-mergeable</emphasis>.
|
||||
Mergeable elements will always attempt to merge together if the elements are similar.
|
||||
Non-mergeable elements in a parent or child flow will always be contained in the resulting flow intact.
|
||||
They will not be modified as part of the merge process.
|
||||
@@ -91,13 +91,13 @@
|
||||
<sect2 id="flow-inheritance-algorithm-mergeable">
|
||||
<title>Mergeable Elements</title>
|
||||
<para>
|
||||
If the elements are of the same type and the keyed attribute are identical, the content of the parent element will be merged with the child element.
|
||||
If the elements are of the same type and their keyed attribute are identical, the content of the parent element will be merged with the child element.
|
||||
The merge algorithm will continue to merge each sub-element of the merging parent and child.
|
||||
Otherwise the parent element is added as a new element to the child.
|
||||
</para>
|
||||
<para>
|
||||
In most cases, elements from a parent flow that are added will be added after elements in the child flow.
|
||||
Exceptions to this rule include actions elements (evaluate, render and set) which will be added at the beginning.
|
||||
Exceptions to this rule include action elements (evaluate, render and set) which will be added at the beginning.
|
||||
This allows for the results of parent actions to be used by child actions.
|
||||
</para>
|
||||
<para>
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
<para>
|
||||
Security is an important concept for any application.
|
||||
End users should not be able to access any portion of a site simply by guessing the URL.
|
||||
Areas of a site that are sensitive must insure that only authorized requested are processed.
|
||||
Areas of a site that are sensitive must ensure that only authorized requested are processed.
|
||||
Spring Security is a proven security platform that can integrate with your application at multiple levels.
|
||||
This section will focus on securing flow execution.
|
||||
</para>
|
||||
@@ -72,7 +72,7 @@
|
||||
<sect1 id="flow-security-listener">
|
||||
<title>The SecurityFlowExecutionListener</title>
|
||||
<para>
|
||||
Defining security rules in the flow by themself will not protect the flow execution.
|
||||
Defining security rules in the flow by themselves will not protect the flow execution.
|
||||
A <code>SecurityFlowExecutionListener</code> must also be defined in the webflow configuration and applied to the flow executor.
|
||||
</para>
|
||||
<programlisting language="xml"><![CDATA[
|
||||
|
||||
@@ -166,7 +166,7 @@
|
||||
If you wish to run your Web Flows in an OSGi environment, you are encouraged to use the <link linkend="jars">SpringSource Bundle Repository</link>.
|
||||
</para>
|
||||
<para>
|
||||
To access Web Flow jars from Maven Central, declare the following dependencies in you pom:
|
||||
To access Web Flow jars from Maven Central, declare the following dependencies in your pom:
|
||||
</para>
|
||||
<programlisting language="xml"><![CDATA[
|
||||
<dependency>
|
||||
|
||||
@@ -18,7 +18,7 @@
|
||||
<para>
|
||||
The example below maps all requests that begin with <code>/spring/</code> to the DispatcherServlet.
|
||||
An <code>init-param</code> is used to provide the <code>contextConfigLocation</code>.
|
||||
This is configuration file for the web application.
|
||||
This is the configuration file for the web application.
|
||||
</para>
|
||||
<programlisting language="xml"><![CDATA[
|
||||
<servlet>
|
||||
|
||||
@@ -180,7 +180,7 @@ java org.springframework.webflow.upgrade.WebFlowUpgrader flow-to-upgrade.xml
|
||||
</para>
|
||||
<programlisting language="xml"><![CDATA[
|
||||
<bean name="/pos.htm" class="org.springframework.webflow.mvc.servlet.FlowController">
|
||||
<constructor-arg ref="flowExecutor"/>
|
||||
<property name="flowExecutor" ref="flowExecutor"/>
|
||||
<property name="flowRequestUrlHandler">
|
||||
<bean class="org.springframework.webflow.context.servlet.WebFlow1FlowUrlHandler"/>
|
||||
</property>
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
<sect1 id="views-introduction">
|
||||
<title>Introduction</title>
|
||||
<para>
|
||||
This chapter shows you how to use the view-state element to render views within a flow.
|
||||
This chapter shows you how to use the <code>view-state</code> element to render views within a flow.
|
||||
</para>
|
||||
</sect1>
|
||||
<sect1 id="view-convention">
|
||||
@@ -85,7 +85,7 @@
|
||||
<title>Allocating view variables</title>
|
||||
<para>
|
||||
Use the <code>var</code> tag to declare a view variable.
|
||||
Like a flow variable, any @Autowired references are automatically restored when the view state resumes.
|
||||
Like a flow variable, any <code>@Autowired</code> references are automatically restored when the view state resumes.
|
||||
</para>
|
||||
<programlisting language="xml"><![CDATA[
|
||||
<var name="searchCriteria" class="com.mycompany.myapp.hotels.SearchCriteria" />]]>
|
||||
@@ -144,7 +144,7 @@
|
||||
<para>
|
||||
Use the <code>model</code> attribute to declare a model object the view binds to.
|
||||
This attribute is typically used with views that render data controls, such as forms.
|
||||
The following example declares the <code>enterBookingDetails</code> state manipulates the <code>booking</code> model:
|
||||
The following example declares an <code>enterBookingDetails</code> state manipulates the <code>booking</code> model:
|
||||
</para>
|
||||
<programlisting language="xml"><![CDATA[
|
||||
<view-state id="enterBookingDetails" model="booking">]]>
|
||||
@@ -209,7 +209,7 @@ public void validateEnterBookingDetails(MessageContext context) {
|
||||
<sect3 id="view-validation=programmatic-validator">
|
||||
<title>Implementing a Validator</title>
|
||||
<para>
|
||||
The second way is to define a separate object, called a Validator, which validates your model object.
|
||||
The second way is to define a separate object, called a <emphasis>Validator</emphasis>, which validates your model object.
|
||||
To do this, create a class that defines a public method with the name <code>validate${state}</code>, where <code>state</code> is the id of your view-state.
|
||||
The method must declare a parameter to accept your model object, and a <code>MessageContext</code> parameter for recording validation error messages.
|
||||
For example:
|
||||
@@ -233,7 +233,7 @@ public class BookingValidator {
|
||||
</para>
|
||||
<para>
|
||||
Validators must be registered as Spring beans employing the naming convention <code>${model}Validator</code> to be detected and invoked automatically.
|
||||
In the example above, Spring 2.5 classpath-scanning would detect the @Component and automatically register it as a bean with the name <code>bookingValidator</code>.
|
||||
In the example above, Spring 2.5 classpath-scanning would detect the <code>@Component</code> and automatically register it as a bean with the name <code>bookingValidator</code>.
|
||||
Then, anytime the <code>booking</code> model needs to be validated, this <code>bookingValidator</code> instance would be invoked for you.
|
||||
</para>
|
||||
</sect3>
|
||||
|
||||
Reference in New Issue
Block a user