Anonymous avatar Anonymous committed f885b0c

o updated docs from wiki for 1.0 final release
Issue number:
Obtained from:
Submitted by:
Reviewed by:

git-svn-id: http://svn.opensymphony.com/svn/xwork/trunk@164 e221344d-f017-0410-9bd5-d282ab1896d7

Comments (0)

Files changed (21)

 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>
 
  <div class="snip-attachments"></div>
  
- <h3 class="heading-1">Actions
-</h3><p class="paragraph"/>Actions are the basic unit of execution...
-<h3 class="heading-1">The Action Interface
-</h3><p class="paragraph"/>The basic interface which all XWork actions must implement. Provides several standard return values like SUCCESS and INPUT. Only contains one method, the<p class="paragraph"/><div class="code"><pre><span class="java&#45;keyword">public</span> <span class="java&#45;object">String</span> execute() <span class="java&#45;keyword">throws</span> Exception;</pre></div>
-<h3 class="heading-1">ActionSupport
-</h3>
-<h3 class="heading-1"><a href="localisation.html">Localization with XWork</a>
-</h3>
-<h3 class="heading-1">ActionContext
-</h3><p class="paragraph"/>The ActionContext provides access to the execution environment in the form of named objects during an Action invocation. A new ActionContext is created for each invocation allowing developers to access/modify these properties in a thread safe manner. The ActionContext makes a number of properties available that are typically set to appropriate values by the framework. In WebWork 2 for example, the ActionContext session map wraps an underlying HttpSession object. This allows access to environment specific properties without tying the core framework to a specific execution environment.<p class="paragraph"/>The ActionContext is acquired through the static ActionContext.getContext() method. The ActionContext is a thread local variable and thus the properties of the ActionContext will be relative to the current request thread. The ActionContext has several methods for commonly used properties as well as get() and set() methods which can be used for application specific properties. 
-<h3 class="heading-1">Lifecycle
-</h3>
-<h3 class="heading-1">No FormBeans?
-</h3><p class="paragraph"/>Xwork / Webwork does not require the use of FormBeans
+ <h3 class="heading-1">Actions</h3><p class="paragraph"/>Actions are the basic unit of execution...
+<h3 class="heading-1">The Action Interface</h3><p class="paragraph"/>The basic interface which all XWork actions must implement. Provides several standard return values like SUCCESS and INPUT. Only contains one method, the<p class="paragraph"/><div class="code"><pre><span class="java&#45;keyword">public</span> <span class="java&#45;object">String</span> execute() <span class="java&#45;keyword">throws</span> Exception;</pre></div>
+<h3 class="heading-1">ActionSupport</h3>
+<h3 class="heading-1"><a href="localisation.html">Localization with XWork</a></h3>
+<h3 class="heading-1">ActionContext</h3><p class="paragraph"/>The ActionContext provides access to the execution environment in the form of named objects during an Action invocation. A new ActionContext is created for each invocation allowing developers to access/modify these properties in a thread safe manner. The ActionContext makes a number of properties available that are typically set to appropriate values by the framework. In WebWork 2 for example, the ActionContext session map wraps an underlying HttpSession object. This allows access to environment specific properties without tying the core framework to a specific execution environment.<p class="paragraph"/>The ActionContext is acquired through the static ActionContext.getContext() method. The ActionContext is a thread local variable and thus the properties of the ActionContext will be relative to the current request thread. The ActionContext has several methods for commonly used properties as well as get() and set() methods which can be used for application specific properties. 
+<h3 class="heading-1">Lifecycle</h3>
+<h3 class="heading-1">No FormBeans?</h3><p class="paragraph"/>Xwork / Webwork does not require the use of FormBeans
 like Struts&#8230;
   </div>
 </body>

docs/components.html

 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>
 
  <div class="snip-attachments"></div>
  
- <h3 class="heading-1">Overview
-</h3><p class="paragraph"/><a href="index.html">XWork</a> provides the ComponentManager interface (and a corresponding implementation in the DefaultComponentManager class) to allow a design pattern known as <b class="bold">Inversion of Control</b> (or <b class="bold">IoC</b> for short) to be applied to your actions or other arbitrary objects. In a nutshell, the IoC pattern allows a parent object (in this case XWork's ComponentManager instance) to control a client object (usually an action, but it could be any object that implements the appropriate <b class="bold">enabler</b>).<p class="paragraph"/>You may also want to look at <a href="http://wiki.opensymphony.com/space/WebWork+2+Components">WebWork 2 Components</a> to see how WW2 uses XWork's IoC architecture.
-<h3 class="heading-1">Why IoC?
-</h3><p class="paragraph"/>So why is IoC useful? It means that you can develop components (generally services of some sort) in a top-down fashion, without the need to build a registry class that the client must then call to obtain the component instance.<p class="paragraph"/>Traditionally when implementing services you are probably used to following steps similar to these:
+ <h3 class="heading-1">Overview</h3><p class="paragraph"/><a href="index.html">XWork</a> provides the ComponentManager interface (and a corresponding implementation in the DefaultComponentManager class) to allow a design pattern known as <b class="bold">Inversion of Control</b> (or <b class="bold">IoC</b> for short) to be applied to your actions or other arbitrary objects. In a nutshell, the IoC pattern allows a parent object (in this case XWork's ComponentManager instance) to control a client object (usually an action, but it could be any object that implements the appropriate <b class="bold">enabler</b>).<p class="paragraph"/>You may also want to look at <a href="http://wiki.opensymphony.com/space/WebWork+2+Components">WebWork 2 Components</a> to see how WW2 uses XWork's IoC architecture.
+<h3 class="heading-1">Why IoC?</h3><p class="paragraph"/>So why is IoC useful? It means that you can develop components (generally services of some sort) in a top-down fashion, without the need to build a registry class that the client must then call to obtain the component instance.<p class="paragraph"/>Traditionally when implementing services you are probably used to following steps similar to these:
 <ol>
 <li>Write the component (eg an ExchangeRateService)</li>
 <li>Write the client class (eg an XWork action)</li>
 <li>Adheres to Law of Demeter. Some people think this is silly, but in practise I've found it works much better. Each class is coupled to only what it actually uses (and it should never use too much) and no more. This encourages smaller responsibility specific classes which leads to cleaner design.</li>
 <li>Allows context to be isolated and explicitly passed around. ThreadLocals may be ok in a web-app, but they aren't well suited for high concurrency async applications (such as message driven applications).</li>
 </ul>
-<h3 class="heading-1">Configuration - xwork.xml
-</h3><p class="paragraph"/>The ComponentInterceptor class is used to apply the IoC pattern to XWork actions (ie, to supply components to actions). The ComponentInterceptor should be declared in the &#60;interceptors&#62; block of xwork.xml as follows:<p class="paragraph"/><div class="code"><pre>&#60;interceptor name=<span class="xml&#45;quote">"component"</class>
+<h3 class="heading-1">Configuration - xwork.xml</h3><p class="paragraph"/>The ComponentInterceptor class is used to apply the IoC pattern to XWork actions (ie, to supply components to actions). The ComponentInterceptor should be declared in the &#60;interceptors&#62; block of xwork.xml as follows:<p class="paragraph"/><div class="code"><pre>&#60;interceptor name=<span class="xml&#45;quote">"component"</class>
         class=<span class="xml&#45;quote">"com.opensymphony.xwork.interceptor.component.ComponentInterceptor"</class>/&#62;</pre></div><p class="paragraph"/>You should ensure that any actions that are to be supplied with components have this interceptor applied. (See <a href="interceptors.html">XWork Interceptors</a> for information on how to apply interceptors to actions.)<p class="paragraph"/>If you want to apply IoC to objects other than actions or other components, you will need to use the ComponentManager object directly.
-<h3 class="heading-1">Writing Component Classes
-</h3><p class="paragraph"/>The actual component class can be virtually anything you like. The only constraints on it are that it must be a concrete class with a default constructor so that XWork can create instances of it as required. Optionally, a component may implement the Initializable and/or Disposable interfaces so it will receive lifecycle events just after it is created or before it is destroyed.
-<h3 class="heading-1">Component Dependencies
-</h3><p class="paragraph"/>One feature that is not immediately obvious is that it is possible for components to depend on other components. For example if the ExchangeRateService described above depended on a Configuration component, XWork will pass the Configuration component through to the ExchangeRateService instance after ExchangeRateService is instantiated. Note that XWork automatically takes care of initializing the components in the correct order, so if A depends on B and C, and B depends on C, the ComponentManager will load C first, then B then A.
-<h3 class="heading-1">Writing Enablers
-</h3><p class="paragraph"/>An enabler should consist of just a single method that accepts a single parameter. The parameter class should either be the component class that is to be enabled, or one of the component's superclasses. XWork does not care what the name of the enabler's method is.<p class="paragraph"/>Here is an example of what the ExchangeRateAware enabler might look like:<p class="paragraph"/><div class="code"><pre><span class="java&#45;keyword">public</span> <span class="java&#45;keyword">interface</span> ExchangeRateAware &#123;
+<h3 class="heading-1">Writing Component Classes</h3><p class="paragraph"/>The actual component class can be virtually anything you like. The only constraints on it are that it must be a concrete class with a default constructor so that XWork can create instances of it as required. Optionally, a component may implement the Initializable and/or Disposable interfaces so it will receive lifecycle events just after it is created or before it is destroyed.
+<h3 class="heading-1">Component Dependencies</h3><p class="paragraph"/>One feature that is not immediately obvious is that it is possible for components to depend on other components. For example if the ExchangeRateService described above depended on a Configuration component, XWork will pass the Configuration component through to the ExchangeRateService instance after ExchangeRateService is instantiated. Note that XWork automatically takes care of initializing the components in the correct order, so if A depends on B and C, and B depends on C, the ComponentManager will load C first, then B then A.
+<h3 class="heading-1">Writing Enablers</h3><p class="paragraph"/>An enabler should consist of just a single method that accepts a single parameter. The parameter class should either be the component class that is to be enabled, or one of the component's superclasses. XWork does not care what the name of the enabler's method is.<p class="paragraph"/>Here is an example of what the ExchangeRateAware enabler might look like:<p class="paragraph"/><div class="code"><pre><span class="java&#45;keyword">public</span> <span class="java&#45;keyword">interface</span> ExchangeRateAware &#123;
     <span class="java&#45;keyword">public</span> void setExchangeRateService(ExchangeRateService exchangeRateService);
 &#125;</pre></div><p class="paragraph"/>Note that typically an enabler would be an interface, however there is nothing to prevent you from using a class instead if you so choose.
-<h3 class="heading-1">Writing "Enabler-aware" Actions
-</h3><p class="paragraph"/>All an action needs to do is implement the relevant enabler interface. XWork will then call the action's enabler method just prior to the action's execution. As a simple example:<p class="paragraph"/><div class="code"><pre><span class="java&#45;keyword">public</span> class MyAction <span class="java&#45;keyword">extends</span> ActionSupport <span class="java&#45;keyword">implements</span> ExchangeRateAware &#123;
+<h3 class="heading-1">Writing "Enabler-aware" Actions</h3><p class="paragraph"/>All an action needs to do is implement the relevant enabler interface. XWork will then call the action's enabler method just prior to the action's execution. As a simple example:<p class="paragraph"/><div class="code"><pre><span class="java&#45;keyword">public</span> class MyAction <span class="java&#45;keyword">extends</span> ActionSupport <span class="java&#45;keyword">implements</span> ExchangeRateAware &#123;
     ExchangeRateService ers;<p class="paragraph"/>    <span class="java&#45;keyword">public</span> void setExchangeRateService(ExchangeRateService exchangeRateService) &#123;
         ers = exchangeRateService;
     &#125;<p class="paragraph"/>    <span class="java&#45;keyword">public</span> <span class="java&#45;object">String</span> execute() <span class="java&#45;keyword">throws</span> Exception &#123;

docs/concepts.html

 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>
 
  <div class="snip-attachments"></div>
  
- <h3 class="heading-1">XWork Core Concepts
-</h3><p class="paragraph"/><a href="index.html">XWork</a> is based on a number of core concepts that helps to explain how the framework works. The core concepts can be broken down into two parts: Architecture Concepts and Terminology.
-<h3 class="heading-1">Architecture Concepts
-</h3>
+ <h3 class="heading-1">XWork Core Concepts</h3><p class="paragraph"/><a href="index.html">XWork</a> is based on a number of core concepts that helps to explain how the framework works. The core concepts can be broken down into two parts: Architecture Concepts and Terminology.
+<h3 class="heading-1">Architecture Concepts</h3>
 <ul class="star">
 <li>Explain Command Driven Architecture (in general)</li>
 <li>Explain the implementation in XWork</li>
 </ul>
-<h3 class="heading-1">Terminology
-</h3>
-<h3 class="heading-1-1">Actions
-</h3><p class="paragraph"/>Actions are classes that get invoked in response to a request, execute some code and return a Result. Actions implement at a minimum a single method, execute(), that defines the entry point called by the framework. This method allows developers to define a unit of work that will be executed each time the Action is called.
-<h3 class="heading-1-1">ActionContext
-</h3><p class="paragraph"/>The ActionContext provides access to the execution environment in the form of named objects during an Action invocation. A new ActionContext is created for each invocation allowing developers to access/modify these properties in a thread safe manner. The ActionContext makes a number of properties available that are typically set to appropriate values by the framework. In WebWork 2 for example, the ActionContext session map wraps an underlying HttpSession object. This allows access to environment specific properties without tying the core framework to a specific execution environment. For more information, see ActionContext in <a href="basics.html">XWork Basics</a>.
-<h3 class="heading-1-1">Interceptors
-</h3><p class="paragraph"/>In XWork, Interceptors are objects that dynamically intercept Action invocations. They provide the developer with the opportunity to define code that can be executed before and/or after the execution of an action. They also have the ability to prevent an action from executing. Interceptors provide developers a way to encapulate common functionality in a re-usable form that can be applied to one or more Actions. See <a href="interceptors.html">XWork Interceptors</a> for further details.
-<h3 class="heading-1-1">Stacks
-</h3><p class="paragraph"/>To handle the case where developers want to apply more than a single Interceptor to an Action, Stacks have been introduced. Stacks are an ordered list of Interceptors and/or other Stacks that get applied when an Action is invoked. Stacks centralize the declaration of Interceptors and provide a convenient way to configure mutiple actions.
-<h3 class="heading-1-1">Results
-</h3><p class="paragraph"/>Results are string constants that Actions return to indicate the status of an Action execution. A standard set of Results are defined by default: error, input, login, none and success.  Developers are, of course, free to create their own Results to indicate more application specific cases.
-<h3 class="heading-1-1">Result Types
-</h3><p class="paragraph"/>Result Types are classes that determine what happens after an Action executes and a Result is returned. Developers are free to create their own Result Types according to the needs of their application or environment. In WebWork 2 for example, Servlet and Velocity Result Types have been created to handle rendering views in web applications.
-<h3 class="heading-1-1">Packages
-</h3><p class="paragraph"/>Packages are a way to group Actions, Results, Result Types, Interceptors and Stacks into a logical unit that shares a common configuration. Packages are similiar to objects in that they can be extended and have individual parts overridden by "sub" packages.
-<h3 class="heading-1-1">ValueStack
-</h3><p class="paragraph"/>The ValueStack is a stack implementation built on top of an OGNL core. The OGNL expression language can be used to traverse the stack and retrieve the desired object. The OGNL expression language provides a number of additional features including: automatic type conversion, method invocation and object comparisons. For more information, see the <span class="nobr"><img src="http://wiki.opensymphony.com/images/external-link.png" alt="&gt;&gt;" border="0"/><a href="http://ognl.org/index.html">OGNL Website</a></span>.
-<h3 class="heading-1-1">Components
-</h3><p class="paragraph"/>XWork provides the ComponentManager interface (and a corresponding implementation in the DefaultComponentManager class) to apply a design pattern known as <b class="bold">Inversion of Control</b> (or IoC for short). In a nutshell, the IoC pattern allows a parent object (in this case XWork's ComponentManager instance) to control a client object (usually an action, but it could be any object that implements the appropriate <b class="bold">enabler</b>). See <a href="components.html">XWork Components</a> for further details.
+<h3 class="heading-1">Terminology</h3>
+<h3 class="heading-1-1">Actions</h3><p class="paragraph"/>Actions are classes that get invoked in response to a request, execute some code and return a Result. Actions implement at a minimum a single method, execute(), that defines the entry point called by the framework. This method allows developers to define a unit of work that will be executed each time the Action is called.
+<h3 class="heading-1-1">ActionContext</h3><p class="paragraph"/>The ActionContext provides access to the execution environment in the form of named objects during an Action invocation. A new ActionContext is created for each invocation allowing developers to access/modify these properties in a thread safe manner. The ActionContext makes a number of properties available that are typically set to appropriate values by the framework. In WebWork 2 for example, the ActionContext session map wraps an underlying HttpSession object. This allows access to environment specific properties without tying the core framework to a specific execution environment. For more information, see ActionContext in <a href="basics.html">XWork Basics</a>.
+<h3 class="heading-1-1">Interceptors</h3><p class="paragraph"/>In XWork, Interceptors are objects that dynamically intercept Action invocations. They provide the developer with the opportunity to define code that can be executed before and/or after the execution of an action. They also have the ability to prevent an action from executing. Interceptors provide developers a way to encapulate common functionality in a re-usable form that can be applied to one or more Actions. See <a href="interceptors.html">XWork Interceptors</a> for further details.
+<h3 class="heading-1-1">Stacks</h3><p class="paragraph"/>To handle the case where developers want to apply more than a single Interceptor to an Action, Stacks have been introduced. Stacks are an ordered list of Interceptors and/or other Stacks that get applied when an Action is invoked. Stacks centralize the declaration of Interceptors and provide a convenient way to configure mutiple actions.
+<h3 class="heading-1-1">Results</h3><p class="paragraph"/>Results are string constants that Actions return to indicate the status of an Action execution. A standard set of Results are defined by default: error, input, login, none and success.  Developers are, of course, free to create their own Results to indicate more application specific cases.
+<h3 class="heading-1-1">Result Types</h3><p class="paragraph"/>Result Types are classes that determine what happens after an Action executes and a Result is returned. Developers are free to create their own Result Types according to the needs of their application or environment. In WebWork 2 for example, Servlet and Velocity Result Types have been created to handle rendering views in web applications.
+<h3 class="heading-1-1">Packages</h3><p class="paragraph"/>Packages are a way to group Actions, Results, Result Types, Interceptors and Stacks into a logical unit that shares a common configuration. Packages are similiar to objects in that they can be extended and have individual parts overridden by "sub" packages.
+<h3 class="heading-1-1">ValueStack</h3><p class="paragraph"/>The ValueStack is a stack implementation built on top of an OGNL core. The OGNL expression language can be used to traverse the stack and retrieve the desired object. The OGNL expression language provides a number of additional features including: automatic type conversion, method invocation and object comparisons. For more information, see the <span class="nobr"><img src="http://wiki.opensymphony.com/images/external-link.png" alt="&gt;&gt;" border="0"/><a href="http://ognl.org/index.html">OGNL Website</a></span>.
+<h3 class="heading-1-1">Components</h3><p class="paragraph"/>XWork provides the ComponentManager interface (and a corresponding implementation in the DefaultComponentManager class) to apply a design pattern known as <b class="bold">Inversion of Control</b> (or IoC for short). In a nutshell, the IoC pattern allows a parent object (in this case XWork's ComponentManager instance) to control a client object (usually an action, but it could be any object that implements the appropriate <b class="bold">enabler</b>). See <a href="components.html">XWork Components</a> for further details.
   </div>
 </body>
 </html>

docs/configuration.html

 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>
 <li>Interceptor stacks - Make it easier to have sets of interceptors you apply together in a certain order. These are also inherited as part of the interceptor definition inheritance. Essentially these are just name mappings to lists of interceptors instead of one Interceptor.</li>
 <li>Namespaces - a new idea of mine, this allows actions to be aliased with the same name, providing they are in different namespaces. With the ServletDispatcher, this equates to the path before the action name, which will allow for J2EE declarative security. Namespaces are optional attributes of package definitions and, if excluded, defaults to "". If the action configuration is not found with the supplied namespace, the "" namespace is checked as the default namespace, which makes it work like we have now (any path works, you get the action aliased with the name).</li>
 </ol>
-<h3 class="heading-1">xwork.xml elements
-</h3>
-<h3 class="heading-1-1">Package
-</h3><p class="paragraph"/>The package element has one required attribute, "name", which acts as the key for later reference to this package. The "extends" attribute is optional and allows one package to inherit the configuration of one or more previous packages including all interceptor, interceptor-stack, and action configurations. Note that the configuration file is processed sequentially down the document, so the package referenced by an "extends" should be defined above the package which extends it. The "abstract" optional attribute allows you to make a package abstract, which will allow you to extend from it without the action configurations defined in the abstract package actually being available at runtime.
-<h3 class="heading-1-1">Namespace
-</h3><p class="paragraph"/>The optional namespace attribute warrants its own discussion section. The namespace attribute allows you to segregate action configurations into namespaces, so that you may use the same action alias in more than one namespace with different classes, parameters, etc. This is in contrast to Webwork 1.x, where all action names and aliases were global and could not be re-used in an application. The default namespace, which is "" (an empty string) is used as a "catch-all" namespace, so if an action configuration is not found in a specified namespace, the default namespace will also be searched. This allows you to have global action configurations outside of the "extends" hierarchy, as well as to allow the previous Webwork 1.x behavior by not specifying namespaces. It is also intended that the namespace functionality can be used for security, for instance by having the path before the action name be used as the namespace by the Webwork 2.0 ServletDispatcher, thus allowing the use of J2EE declarative security on paths to be easily implemented and maintained.
-<h3 class="heading-1-1">Result-Type
-</h3><p class="paragraph"/>Result types define classes and map them to names to be referred in the action configuration results. This serves as a shorthand name-value pair for these classes.
-<h3 class="heading-1-1">Interceptors
-</h3><p class="paragraph"/>Interceptors also serve as a name-value pairing for referring to specific Interceptor classes by a shorthand name where we use interceptor-ref elements, such as in Interceptor stacks and action configurations.
-<h3 class="heading-1-1">Interceptor-Stack
-</h3><p class="paragraph"/>The interceptor-stack element allows you to assign a name for later referencing via interceptor-ref to an ordered list of interceptors. This allows you to create standard groups of interceptors to be used in a certain order. The interceptor stack name/value pairs are stored in the same map as the interceptor definitions, so anywhere you use an interceptor-ref to refer to an interceptor you may also refer to an interceptor stack.
-<h3 class="heading-1-1">Interceptor Parameterization
-</h3><p class="paragraph"/>Interceptors are instantiated and stored at the ActionConfig level, i.e. there will be one instance per action configured in xwork.xml. These Interceptor instances may be parameterized at either the declaration level, where you map an Interceptor class to a name to be referenced later, like so:<p class="paragraph"/><div class="code"><pre>&#60;interceptor name=<span class="java&#45;quote">"test"</span> class=<span class="java&#45;quote">"com.opensymphony.xwork.TestInterceptor"</span>&#62;
+<h3 class="heading-1">xwork.xml elements</h3>
+<h3 class="heading-1-1">Package</h3><p class="paragraph"/>The package element has one required attribute, "name", which acts as the key for later reference to this package. The "extends" attribute is optional and allows one package to inherit the configuration of one or more previous packages including all interceptor, interceptor-stack, and action configurations. Note that the configuration file is processed sequentially down the document, so the package referenced by an "extends" should be defined above the package which extends it. The "abstract" optional attribute allows you to make a package abstract, which will allow you to extend from it without the action configurations defined in the abstract package actually being available at runtime.
+<h3 class="heading-1-1">Namespace</h3><p class="paragraph"/>The optional namespace attribute warrants its own discussion section. The namespace attribute allows you to segregate action configurations into namespaces, so that you may use the same action alias in more than one namespace with different classes, parameters, etc. This is in contrast to Webwork 1.x, where all action names and aliases were global and could not be re-used in an application. The default namespace, which is "" (an empty string) is used as a "catch-all" namespace, so if an action configuration is not found in a specified namespace, the default namespace will also be searched. This allows you to have global action configurations outside of the "extends" hierarchy, as well as to allow the previous Webwork 1.x behavior by not specifying namespaces. It is also intended that the namespace functionality can be used for security, for instance by having the path before the action name be used as the namespace by the Webwork 2.0 ServletDispatcher, thus allowing the use of J2EE declarative security on paths to be easily implemented and maintained.
+<h3 class="heading-1-1">Result-Type</h3><p class="paragraph"/>Result types define classes and map them to names to be referred in the action configuration results. This serves as a shorthand name-value pair for these classes.
+<h3 class="heading-1-1">Interceptors</h3><p class="paragraph"/>Interceptors also serve as a name-value pairing for referring to specific Interceptor classes by a shorthand name where we use interceptor-ref elements, such as in Interceptor stacks and action configurations.
+<h3 class="heading-1-1">Interceptor-Stack</h3><p class="paragraph"/>The interceptor-stack element allows you to assign a name for later referencing via interceptor-ref to an ordered list of interceptors. This allows you to create standard groups of interceptors to be used in a certain order. The interceptor stack name/value pairs are stored in the same map as the interceptor definitions, so anywhere you use an interceptor-ref to refer to an interceptor you may also refer to an interceptor stack.
+<h3 class="heading-1-1">Interceptor Parameterization</h3><p class="paragraph"/>Interceptors are instantiated and stored at the ActionConfig level, i.e. there will be one instance per action configured in xwork.xml. These Interceptor instances may be parameterized at either the declaration level, where you map an Interceptor class to a name to be referenced later, like so:<p class="paragraph"/><div class="code"><pre>&#60;interceptor name=<span class="java&#45;quote">"test"</span> class=<span class="java&#45;quote">"com.opensymphony.xwork.TestInterceptor"</span>&#62;
     &#60;param name=<span class="java&#45;quote">"foo"</span>&#62;expectedFoo&#60;/param&#62;
 &#60;/interceptor&#62;</pre></div><p class="paragraph"/>or at the interceptor-ref level, either inside an interceptor-stack or in an action declaration, like so:<p class="paragraph"/><div class="code"><pre>&#60;interceptor&#45;ref name=<span class="java&#45;quote">"test"</span>&#62;
     &#60;param name=<span class="java&#45;quote">"expectedFoo"</span>&#62;expectedFoo&#60;/param&#62;
 &#60;/interceptor&#45;ref&#62;</pre></div><p class="paragraph"/>Although it is allowed by the DTD, parameters applied to interceptor-refs which refer to interceptor-stack elements will NOT be applied, and will cause a warning message.
-<h3 class="heading-1-1">Global-results
-</h3><p class="paragraph"/>The global results allows you to define result mappings which will be used as defaults for all action configurations and will be automatically inherited by all action configurations in this package and all packages which extend this package.
-<h3 class="heading-1-1">Action
-</h3><p class="paragraph"/>The action element allows the mapping of names to action classes. These names are used, along with the namespace described above, to retrieve the action config from the configuration. The action may also be parameterized by using the param elements, as above, which will set parameters into the Action at execution (with the help of the StaticParametersInterceptor).<p class="paragraph"/>The action may also have one or more results mapped to string return codes, such as "success", "error", or "input", which are the default 3 return states for actions, although ANY return string may be used and mapped to a result. The result, which is mapped to a result class by the "type" attribute which refers to the result-type name defined above, may also be parameterized by using the param element.<p class="paragraph"/>There is one shortcut when defining results, as a lot of the time a result will have only one parameter (which is often a location to redirect to (when using XWork in the web sense)).<p class="paragraph"/>Here is the long form of a result with a single location parameter:<p class="paragraph"/><div class="code"><pre>&#60;result name=<span class="java&#45;quote">"test"</span>&#62;
+<h3 class="heading-1-1">Global-results</h3><p class="paragraph"/>The global results allows you to define result mappings which will be used as defaults for all action configurations and will be automatically inherited by all action configurations in this package and all packages which extend this package.
+<h3 class="heading-1-1">Action</h3><p class="paragraph"/>The action element allows the mapping of names to action classes. These names are used, along with the namespace described above, to retrieve the action config from the configuration. The action may also be parameterized by using the param elements, as above, which will set parameters into the Action at execution (with the help of the StaticParametersInterceptor).<p class="paragraph"/>The action may also have one or more results mapped to string return codes, such as "success", "error", or "input", which are the default 3 return states for actions, although ANY return string may be used and mapped to a result. The result, which is mapped to a result class by the "type" attribute which refers to the result-type name defined above, may also be parameterized by using the param element.<p class="paragraph"/>There is one shortcut when defining results, as a lot of the time a result will have only one parameter (which is often a location to redirect to (when using XWork in the web sense)).<p class="paragraph"/>Here is the long form of a result with a single location parameter:<p class="paragraph"/><div class="code"><pre>&#60;result name=<span class="java&#45;quote">"test"</span>&#62;
     &#60;param name=<span class="java&#45;quote">"location"</span>&#62;foo.jsp&#60;/param&#62;
 &#60;/result&#62;</pre></div><p class="paragraph"/>and this is the 'shortcut' form:<p class="paragraph"/><div class="code"><pre>&#60;result name=<span class="java&#45;quote">"test"</span>&#62;foo.jsp&#60;/result&#62;</pre></div><p class="paragraph"/>Note that this shortcut <b class="bold">only</b> works when there is a single parameter for the result and the result has defined what its default parameter is.<p class="paragraph"/>The action may also define one or more interceptor refs to either interceptors or interceptor stacks to be applied before and after the action execution (see the section on Interceptors below). The ordering of these interceptor refs determines the order in which they will be applied.
-<h3 class="heading-1-1">Includes - using multiple configuration files
-</h3><p class="paragraph"/>The xwork.xml configuration file may be broken up into several files, each with its own set of package declarations, by using the &#60;include&#62; element zero or more times at the bottom of your xwork.xml file, like so:<p class="paragraph"/><div class="code"><pre>&#60;include file=<span class="java&#45;quote">"includeTest.xml"</span>/&#62;</pre></div><p class="paragraph"/>These files will be processed, in order, in the same manner as the main xwork.xml, thus may have all of the same structures, including the &#60;include&#62; element. Although it is, therefore, possible to have packages in configuration files listed later in an include element extend packages defined in an earlier included file, it is not recommended. It should be considered best practice, in the case of using multiple configuration files, to declare default packages meant to be extended in the xwork.xml and to have no dependencies between sub-configuration files.
-<h3 class="heading-1">Configuration Providers
-</h3><p class="paragraph"/>XWork configuration is handled through classes which implement the ConfigurationProvider interface.  The default implementation is the XmlConfigurationProvider class.  You can either create a new provider by implementing the ConfigurationProvider interface or you can extend the XmlConfigurationProvider class.  The XmlConfigurationProvider class includes a protected method called getInputStream() which is called to acquire the configuration InputStream which is expected to be an XML data stream.  The default implementation looks for a file called xwork.xml in the class path but by overriding the getInputStream() method you can pull configuration data from any source.<p class="paragraph"/>Custom configuration providers must be registered with the ConfigurationManager before they will be used to load configuration data.  If no custom configuration providers are registered then the default configuration provider is used.  If any custom configuration providers are registered then the default configuration provider will no longer be used (although you could add a new instance of it yourself to include it in the list of providers which is searched).  To add a configuration provider just call the ConfigurationManager.addConfigurationProvider() method with the custom configuration provider as the argument.
+<h3 class="heading-1-1">Includes - using multiple configuration files</h3><p class="paragraph"/>The xwork.xml configuration file may be broken up into several files, each with its own set of package declarations, by using the &#60;include&#62; element zero or more times at the bottom of your xwork.xml file, like so:<p class="paragraph"/><div class="code"><pre>&#60;include file=<span class="java&#45;quote">"includeTest.xml"</span>/&#62;</pre></div><p class="paragraph"/>These files will be processed, in order, in the same manner as the main xwork.xml, thus may have all of the same structures, including the &#60;include&#62; element. Although it is, therefore, possible to have packages in configuration files listed later in an include element extend packages defined in an earlier included file, it is not recommended. It should be considered best practice, in the case of using multiple configuration files, to declare default packages meant to be extended in the xwork.xml and to have no dependencies between sub-configuration files.
+<h3 class="heading-1">Configuration Providers</h3><p class="paragraph"/>XWork configuration is handled through classes which implement the ConfigurationProvider interface.  The default implementation is the XmlConfigurationProvider class.  You can either create a new provider by implementing the ConfigurationProvider interface or you can extend the XmlConfigurationProvider class.  The XmlConfigurationProvider class includes a protected method called getInputStream() which is called to acquire the configuration InputStream which is expected to be an XML data stream.  The default implementation looks for a file called xwork.xml in the class path but by overriding the getInputStream() method you can pull configuration data from any source.<p class="paragraph"/>Custom configuration providers must be registered with the ConfigurationManager before they will be used to load configuration data.  If no custom configuration providers are registered then the default configuration provider is used.  If any custom configuration providers are registered then the default configuration provider will no longer be used (although you could add a new instance of it yourself to include it in the list of providers which is searched).  To add a configuration provider just call the ConfigurationManager.addConfigurationProvider() method with the custom configuration provider as the argument.
   </div>
 </body>
 </html>

docs/conversion.html

 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>
   <span class="java&#45;keyword">public</span> void setContact1(Contact contact) &#123; <span class="java&#45;keyword">this</span>.contact1 = contact; &#125;
   <span class="java&#45;keyword">public</span> void setContact2(Contact contact) &#123; <span class="java&#45;keyword">this</span>.contact2 = contact; &#125;<p class="paragraph"/>  <span class="java&#45;keyword">public</span> <span class="java&#45;object">String</span> execute() &#123; &#8230; &#125;
 &#125;</pre></div><p class="paragraph"/>What we're expecting from the UI is for contact to be "1", the primary key of the contact.  We want the type converter to convert the string "1" to the Contact with a contactId of 1.  Likewise, we'd like the converter to be able to reverse the operation.  When displayed, a Contact object should print out its contactId as a String.<p class="paragraph"/>The first step is to create our custom TypeConverter:<p class="paragraph"/><div class="code"><pre><span class="java&#45;keyword">public</span> class ContactConverter <span class="java&#45;keyword">extends</span> DefaultTypeConverter &#123;
-  <span class="java&#45;keyword">public</span> <span class="java&#45;object">Object</span> convertValue(Map contact, <span class="java&#45;object">Object</span> value, <span class="java&#45;object">Class</span> toType) &#123;
+  <span class="java&#45;keyword">public</span> <span class="java&#45;object">Object</span> convertValue(Map ognlContext, <span class="java&#45;object">Object</span> value, <span class="java&#45;object">Class</span> toType) &#123;
     <span class="java&#45;keyword">if</span>( toType == <span class="java&#45;object">String</span>.class ) &#123;
       Contact contact = (Contact)value;
       <span class="java&#45;keyword">return</span> <span class="java&#45;keyword">new</span> <span class="java&#45;object">String</span>(contact.getContactId());
     &#125;
   &#125;
 &#125;</pre></div><p class="paragraph"/>The next part is to bind our ContactConverter to the previous AddContactAction.  I'll bind the ContactConverter to the AddContactAction by creating a file called AddContactAction-conversion.properties that's in the same directory as the AddContactAction class.<p class="paragraph"/>I would then populate the properties file as follows:<p class="paragraph"/><div class="code"><pre>contact1 = com.acme.ContactConverter
-contact2 = com.acme.ContactConverter</pre></div><p class="paragraph"/>Now, when XWork attempts to populate your object from parameters, you'll be given the actual instances of Contact from your database.<p class="paragraph"/>Having said all that, I can't really recommend doing database lookups here as a best practice.  In fact, I'd say it's not such a good idea, but it does illustrate type converters well :)  Any exception thrown here would be buried deep in the bowels of XWork code.<p class="paragraph"/>
+contact2 = com.acme.ContactConverter</pre></div><p class="paragraph"/>Now, when XWork attempts to populate your object from parameters, you'll be given the actual instances of Contact from your database.<p class="paragraph"/>Having said all that, I can't really recommend doing database lookups here as a best practice.  In fact, I'd say it's not such a good idea, but it does illustrate type converters well :)  Any exception thrown here will be handled as described in <a href="conversionerrorhandling.html">Type Conversion Error Handling</a><p class="paragraph"/>
   </div>
 </body>
 </html>

docs/conversionerrorhandling.html

+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
+  <link type="text/css" href="main.css" rel="STYLESHEET"/>
+</head>
+<body>
+  <div id="page-logo">
+    <a href="index.html">XWork Documentation</a>
+  </div>
+    <div class="snip-title">
+	  <h1 class="snip-name">Type Conversion Error Handling
+  
+  </h1>
+  </div>
+<div id="snip-content" class="snip-content">
+
+ <div class="snip-attachments"></div>
+ 
+ Type conversion errors are handled by the XWorkConverter whenever any Exception is thrown by a converter during converting a value. Type conversion errors are added to a Map stored in the ActionContext which is available via ActionContext.getContext().getConversionErrors(). This map is a map of field name to values which will allow you to access the original value which failed conversion.<p class="paragraph"/>There are 2 ways of automatically populating field errors with the type conversion errors into the field errors of the Action. The first will populate all of the field errors from the conversion errors and is implemented as an Interceptor. There are actually 2 Interceptors, one in XWork and one in WebWork which extends the one in XWork. They differ in the implementation of the method<p class="paragraph"/><div class="code"><pre><span class="java&#45;keyword">protected</span> <span class="java&#45;object">boolean</span> shouldAddError(<span class="java&#45;object">String</span> propertyName, <span class="java&#45;object">Object</span> value)</pre></div><p class="paragraph"/>The XWork version always returns true, whereas the WebWork Interceptor returns false for values of null, "", and {""}, preventing type conversion exceptions for these common empty values from propogating to the field errors of the Action. The WebWork version of this Interceptor has been added to the webwork-defaults.xml and to the defaultStack defined therein.<p class="paragraph"/>If you choose not to use this Interceptor, you can choose to enable this on a per-field basis by using the Validation framework with the new field validator added for this, defined in the validators.xml file like this:<p class="paragraph"/><div class="code"><pre>&#60;validator name=<span class="java&#45;quote">"conversion"</span> class=<span class="java&#45;quote">"com.opensymphony.xwork.validator.validators.ConversionErrorFieldValidator"</span>/&#62;</pre></div><p class="paragraph"/>This validator will look up the conversion errors and, if it finds a conversion error for the field it is applied to, it will add the appropriate error message to the Action.<p class="paragraph"/>Both of these methods use the<p class="paragraph"/><div class="code"><pre>XWorkConverter.getConversionErrorMessage(propertyName, stack)</pre></div><p class="paragraph"/>which looks up the type conversion error message for the property name as was done previously, by looking for a message keyed by "invalid.fieldvalue.propertyName" and using a default value if it is not found.
+
+  </div>
+</body>
+</html>

docs/dependencies.html

 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>
  <div class="snip-attachments"></div>
  
  Dependencies are always an important issue for me. I like to know <i class="italic">exactly</i> what dependencies any module has.<p class="paragraph"/>Here are the dependencies for <a href="index.html">XWork</a>, split into runtime and compile time dependencies. You may also want to look at the <a href="http://wiki.opensymphony.com/space/WebWork+2+Dependencies">WebWork 2 Dependencies</a>.
-<h3 class="heading-1-1">Runtime Dependencies
-</h3>
+<h3 class="heading-1-1">Runtime Dependencies</h3>
 These are stored in CVS in the <b class="bold">lib/core</b> directory.<p class="paragraph"/><table class="wiki-table" cellpadding="0" cellspacing="0" border="0"><tr><th>JAR</th><th>Version</th><th>Link</th></tr><tr class="table-odd"><td>commons-logging.jar</td><td>1.0</td><td><span class="nobr"><img src="http://wiki.opensymphony.com/images/external-link.png" alt="&gt;&gt;" border="0"/><a href="http://jakarta.apache.com/commons/logging.html">homepage</a></span></td></tr><tr class="table-even"><td>mail.jar</td><td>??</td><td>??</td></tr><tr class="table-odd"><td>ognl-2.5.1.jar</td><td>2.5.1</td><td><span class="nobr"><img src="http://wiki.opensymphony.com/images/external-link.png" alt="&gt;&gt;" border="0"/><a href="http://www.ognl.org">homepage</a></span></td></tr><tr class="table-even"><td>oscore-2.1.0.jar</td><td>2.1.0</td><td><a href="http://wiki.opensymphony.com/space/OSCore">OSCore</a></td></tr></table>
-<h3 class="heading-1-1">Compile time dependencies
-</h3>
+<h3 class="heading-1-1">Compile time dependencies</h3>
 These are stored in CVS in the <b class="bold">lib/build</b> directory.<p class="paragraph"/><table class="wiki-table" cellpadding="0" cellspacing="0" border="0"><tr><th>JAR</th><th>Version</th><th>Link</th></tr><tr class="table-odd"><td>clover-1.0.jar</td><td>1.0</td><td><span class="nobr"><img src="http://wiki.opensymphony.com/images/external-link.png" alt="&gt;&gt;" border="0"/><a href="http://www.thecortex.net/clover">homepage</a></span></td></tr><tr class="table-even"><td>junit-3.8.1.jar</td><td>3.8.1</td><td><span class="nobr"><img src="http://wiki.opensymphony.com/images/external-link.png" alt="&gt;&gt;" border="0"/><a href="http://www.junit.org">homepage</a></span></td></tr><tr class="table-odd"><td>mockobjects-12-7-2002.jar</td><td>12-7-2002 snapshot</td><td><span class="nobr"><img src="http://wiki.opensymphony.com/images/external-link.png" alt="&gt;&gt;" border="0"/><a href="http://www.mockobjects.com">homepage</a></span></td></tr><tr class="table-even"><td>velocity.jar</td><td>??</td><td><span class="nobr"><img src="http://wiki.opensymphony.com/images/external-link.png" alt="&gt;&gt;" border="0"/><a href="http://jakarta.apache.org/velocity">homepage</a></span></td></tr></table>
 
   </div>

docs/documentation.html

 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>
 
  <div class="snip-attachments"></div>
  
- <h3 class="heading-1"><a href="intro.html">Xwork Introduction</a>
-</h3>
+ <h3 class="heading-1"><a href="intro.html">Xwork Introduction</a></h3>
 <ul class="star">
 <li>What is Xwork?</li>
 <li>How does Webwork 2.0 relate to Xwork?</li>
 </ul>
-<h3 class="heading-1"><a href="concepts.html">XWork Core Concepts</a>
-</h3>
+<h3 class="heading-1"><a href="concepts.html">XWork Core Concepts</a></h3>
 <ul class="star">
 <li>Terminonlogy</li>
 </ul>
-<h3 class="heading-1"><a href="basics.html">Xwork Basics</a>
-</h3>
+<h3 class="heading-1"><a href="basics.html">Xwork Basics</a></h3>
 <ul class="star">
 <li>Actions</li>
 <li>The Action Interface</li>
 <li>Lifecycle</li>
 <li>No Formbeans?</li>
 </ul>
-<h3 class="heading-1"><a href="configuration.html">Xwork Configuration</a>
-</h3>
+<h3 class="heading-1"><a href="configuration.html">Xwork Configuration</a></h3>
 <ul class="star">
 <li>Xwork.xml</li>
 <li>Xwork.xml elements</li>
 </ul>
-<h3 class="heading-1"><a href="ognl.html">Ognl</a>
-</h3>
-<h3 class="heading-1"><a href="conversion.html">Type Conversion</a>
-</h3>
-<h3 class="heading-1"><a href="interceptors.html">Xwork Interceptors</a>
-</h3>
+<h3 class="heading-1"><a href="ognl.html">Ognl</a></h3>
+<h3 class="heading-1"><a href="conversion.html">Type Conversion</a></h3>
+<h3 class="heading-1"><a href="conversionerrorhandling.html">Type Conversion Error Handling</a></h3>
+<h3 class="heading-1"><a href="interceptors.html">Xwork Interceptors</a></h3>
 <ul class="star">
 <li>Utility Interceptors</li>
 <li>Parameter Interceptors</li>
 <li>ResultInterceptor, StackInterceptor, ChainingInterceptor</li>
 </ul>
-<h3 class="heading-1"><a href="validation.html">Xwork Validation Framework</a>
-</h3>
+<h3 class="heading-1"><a href="validation.html">Xwork Validation Framework</a></h3>
 <ul class="star">
 <li>Turning on Validation</li>
 <li>The ValidationInterceptor</li>
 <li><a href="fieldvalidator.html">Using the VisitorFieldValidator</a></li>
 <li><a href="validationexample.html">A WebWork2 Example of Xwork Validation</a></li>
 </ul>
-<h3 class="heading-1"><a href="components.html">XWork Components</a>
-</h3>
+<h3 class="heading-1"><a href="components.html">XWork Components</a></h3>
 <ul class="star">
 <li>Overview</li>
 <li>Why IoC?</li>
 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>

docs/featurecomparison.html

 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>

docs/fieldvalidator.html

 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>
  <div class="snip-attachments"></div>
  
  see the <a href="validation.html">Xwork Validation Framework</a>
-<h3 class="heading-1">What is the VisitorFieldValidator
-</h3><p class="paragraph"/>The VisitorFieldValidator allows you to forward validation to object properties of your action using the objects own validation files. This allows you to use the ModelDriven development pattern and manage your validations for your models in one place, where they belong, next to your model classes. The VisitorFieldValidator can handle either simple Object properties, Collections of Objects, or Arrays.
-<h3 class="heading-1">Applying the VisitorFieldValidator
-</h3><p class="paragraph"/>The VisitorFieldValidator is applied like any other field validator in a validation.xml file (see <a href="validation.html">Xwork Validation Framework</a>).<p class="paragraph"/><div class="code"><pre>&#60;field name=<span class="java&#45;quote">"bean"</span>&#62;
+<h3 class="heading-1">What is the VisitorFieldValidator</h3><p class="paragraph"/>The VisitorFieldValidator allows you to forward validation to object properties of your action using the objects own validation files. This allows you to use the ModelDriven development pattern and manage your validations for your models in one place, where they belong, next to your model classes. The VisitorFieldValidator can handle either simple Object properties, Collections of Objects, or Arrays.
+<h3 class="heading-1">Applying the VisitorFieldValidator</h3><p class="paragraph"/>The VisitorFieldValidator is applied like any other field validator in a validation.xml file (see <a href="validation.html">Xwork Validation Framework</a>).<p class="paragraph"/><div class="code"><pre>&#60;field name=<span class="java&#45;quote">"bean"</span>&#62;
     &#60;field&#45;validator type=<span class="java&#45;quote">"visitor"</span>&#62;
         &#60;param name=<span class="java&#45;quote">"context"</span>&#62;anotherContext&#60;/param&#62;
         &#60;message&#62;bean: &#60;/message&#62;
 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>
  <div class="snip-attachments"></div>
  
  XWork is a generic command pattern framework, that was split out of <a href="http://wiki.opensymphony.com/space/WebWork">WebWork</a> and forms the core of <a href="http://wiki.opensymphony.com/space/WebWork2">WebWork2</a>.
-<h3 class="heading-1">Overview
-</h3>
+<h3 class="heading-1">Overview</h3>
 <ul class="star">
 <li><a href="statement.html">XWork 1.0 Mission Statement</a></li>
 <li><a href="roadmap.html">XWork Roadmap</a></li>
 </ul>
-<h3 class="heading-1">Documentation
-</h3>
+<h3 class="heading-1">Documentation</h3>
 <ul class="star">
+<li>XWork FAQ</li>
 <li><a href="documentation.html">XWork Documentation</a></li>
 <li><a href="dependencies.html">XWork Dependencies</a></li>
 </ul>
-<h3 class="heading-1">Miscellaneous
-</h3>
+<h3 class="heading-1">Miscellaneous</h3>
 <ul class="star">
 <li>For Maven generated reports, see <span class="nobr"><img src="http://wiki.opensymphony.com/images/external-link.png" alt="&gt;&gt;" border="0"/><a href="http://opensymphony.indigoegg.com/xwork/index.html">&#104;ttp://opensymphony.indigoegg.com/xwork/</a></span></li>
 </ul>
-<h3 class="heading-1">CVS Download
-</h3>
+<h3 class="heading-1">CVS Download</h3>
 <ul class="star">
 <li>For download instuctions code go to <span class="nobr"><img src="http://wiki.opensymphony.com/images/external-link.png" alt="&gt;&gt;" border="0"/><a href="https://xwork.dev.java.net/servlets/ProjectSource">&#104;ttps://xwork.dev.java.net/servlets/ProjectSource</a></span></li>
 </ul>

docs/interceptors.html

 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>
 
  <div class="snip-attachments"></div>
  
- <h3 class="heading-1">Overview
-</h3><p class="paragraph"/>Interceptors allow you to define code to be executed before and/or after the execution of an action. They are defined outside the action class, yet have access to the action and the action execution environment at runtime, allowing you to encapsulate cross-cutting code and provide separation of concerns.<p class="paragraph"/>Interceptors are given the ActionInvocation object at runtime, and may do whatever processing needed, then forward processing to the rest of the ActionInvocation, which will either call the next Interceptor or the Action, if there are no more Interceptors, and do whatever post-processing needed.<p class="paragraph"/>Interceptors may also decide to short-circuit processing and return whatever result string desired WITHOUT forwarding processing, thus keeping the Action from executing. This ability should be used with caution, however, as any data loading or processing expected to be done by the Action will not happen.<p class="paragraph"/>Here is the invoke() method from ActionInvocation, which calls the Interceptors and the Action:<p class="paragraph"/><div class="code"><pre><span class="java&#45;keyword">public</span> <span class="java&#45;object">String</span> invoke() <span class="java&#45;keyword">throws</span> Exception &#123;
+ <h3 class="heading-1">Overview</h3><p class="paragraph"/>Interceptors allow you to define code to be executed before and/or after the execution of an action. They are defined outside the action class, yet have access to the action and the action execution environment at runtime, allowing you to encapsulate cross-cutting code and provide separation of concerns.<p class="paragraph"/>Interceptors are given the ActionInvocation object at runtime, and may do whatever processing needed, then forward processing to the rest of the ActionInvocation, which will either call the next Interceptor or the Action, if there are no more Interceptors, and do whatever post-processing needed.<p class="paragraph"/>Interceptors may also decide to short-circuit processing and return whatever result string desired WITHOUT forwarding processing, thus keeping the Action from executing. This ability should be used with caution, however, as any data loading or processing expected to be done by the Action will not happen.<p class="paragraph"/>Here is the invoke() method from ActionInvocation, which calls the Interceptors and the Action:<p class="paragraph"/><div class="code"><pre><span class="java&#45;keyword">public</span> <span class="java&#45;object">String</span> invoke() <span class="java&#45;keyword">throws</span> Exception &#123;
         <span class="java&#45;keyword">if</span> (executed) &#123;
             <span class="java&#45;keyword">throw</span> <span class="java&#45;keyword">new</span> IllegalStateException(<span class="java&#45;quote">"Action has already executed"</span>);
         &#125;<p class="paragraph"/>        <span class="java&#45;keyword">if</span> (interceptors.hasNext()) &#123;
         before(invocation);<p class="paragraph"/>        result = invocation.invoke();
         after(invocation);<p class="paragraph"/>        <span class="java&#45;keyword">return</span> result;
     &#125;</pre></div><p class="paragraph"/>Here we can see that the Interceptor calls back into the ActionInvocation.invoke() to tell the ActionInvocation to continue down the chain and eventually executes the Action. It is here that the Interceptor can decide not to forward to the rest of the Interceptors and the Action, and choose instead to return a return code.<p class="paragraph"/>It is also important to know what the AroundInterceptor is doing when you extend it to implement your own Interceptors.<p class="paragraph"/>The AroundInterceptor defines a base class for interceptor implementations. It delegates calls to subclasses, which must implement the abstract methods before() and after(). The before() call is first called, then the rest of the ActionInvocation is called and the String result is saved (and is available to the Interceptor implementation during the after() method). Finally, the after() method is called and the result is returned. 
-<h3 class="heading-1"><a name="Utility"/><a href="interceptors.html#Utility" title="Permalink to Utility"><img src="http://wiki.opensymphony.com/images/permalink.png" alt="" border="0"/></a> Utility Interceptors
-</h3><p class="paragraph"/>The TimerInterceptor and LoggingInterceptor are provided as simple examples and utilities. 
+<h3 class="heading-1"><a name="Utility"/><a href="interceptors.html#Utility" title="Permalink to Utility"><img src="http://wiki.opensymphony.com/images/permalink.png" alt="" border="0"/></a> Utility Interceptors</h3><p class="paragraph"/>The TimerInterceptor and LoggingInterceptor are provided as simple examples and utilities. 
 <ul class="star">
 <li>The <b class="bold">LoggingInterceptor</b> simply logs before and after executing the rest of the ActionInvocation.</li>
 <li>The <b class="bold">TimerInterceptor</b> times the execution of the remainder of the ActionInvocation.</li>
         <span class="java&#45;object">long</span> executionTime = <span class="java&#45;object">System</span>.currentTimeMillis() &#45; startTime;
         log.info(<span class="java&#45;quote">"Processed action "</span> + dispatcher.getProxy().getActionName() + <span class="java&#45;quote">" in "</span> + executionTime + <span class="java&#45;quote">"ms."</span>);<p class="paragraph"/>        <span class="java&#45;keyword">return</span> result;
     &#125;</pre></div><p class="paragraph"/>It is important to remember to call <b class="bold">invoke()</b> on the ActionInvocation if you directly implement Interceptor, otherwise the rest of the Interceptors and the Action will not be executed.
-<h3 class="heading-1"><a name="Parameter"/><a href="interceptors.html#Parameter" title="Permalink to Parameter"><img src="http://wiki.opensymphony.com/images/permalink.png" alt="" border="0"/></a> Parameter Interceptors - populating your Action
-</h3><p class="paragraph"/>The StaticParametersInterceptor and ParametersInterceptor populate your Action fields during the ActionInvocation execution. 
+<h3 class="heading-1"><a name="Parameter"/><a href="interceptors.html#Parameter" title="Permalink to Parameter"><img src="http://wiki.opensymphony.com/images/permalink.png" alt="" border="0"/></a> Parameter Interceptors - populating your Action</h3><p class="paragraph"/>The StaticParametersInterceptor and ParametersInterceptor populate your Action fields during the ActionInvocation execution. 
 <ul class="star">
 <li>The <b class="bold">StaticParametersInterceptor</b> applies the parameters defined in the Action configuration with the &#60;param&#62; elements.</li>
 <li>The <b class="bold">ParametersInterceptor</b> populates the Action with the parameters passed in as part of the request.</li>
 </ul><p class="paragraph"/>The StaticParametersInterceptor should be applied before the ParametersInterceptor so that the static parameters may be set as the defaults and overridden by the request parameters.
-<h3 class="heading-1"><a name="ModelDriven"/><a href="interceptors.html#ModelDriven" title="Permalink to ModelDriven"><img src="http://wiki.opensymphony.com/images/permalink.png" alt="" border="0"/></a> ModelDrivenInterceptor - choosing your model
-</h3><p class="paragraph"/>Normally, the <b class="bold">StaticParameterInterceptor</b> and the <b class="bold">ParametersInterceptor</b> apply themselves directly to the Action.  Using the ModelDrivenInterceptor, you can specify an alternate object to have the parameters applied to instead.<p class="paragraph"/>Consider the following Action:<p class="paragraph"/><div class="code"><pre><span class="java&#45;keyword">public</span> class AddContactAction <span class="java&#45;keyword">implements</span> Action &#123;
+<h3 class="heading-1"><a name="ModelDriven"/><a href="interceptors.html#ModelDriven" title="Permalink to ModelDriven"><img src="http://wiki.opensymphony.com/images/permalink.png" alt="" border="0"/></a> ModelDrivenInterceptor - choosing your model</h3><p class="paragraph"/>Normally, the <b class="bold">StaticParameterInterceptor</b> and the <b class="bold">ParametersInterceptor</b> apply themselves directly to the Action.  Using the ModelDrivenInterceptor, you can specify an alternate object to have the parameters applied to instead.<p class="paragraph"/>Consider the following Action:<p class="paragraph"/><div class="code"><pre><span class="java&#45;keyword">public</span> class AddContactAction <span class="java&#45;keyword">implements</span> Action &#123;
   <span class="java&#45;keyword">private</span> <span class="java&#45;object">String</span> name;
   <span class="java&#45;keyword">private</span> <span class="java&#45;object">String</span> addr;
   <span class="java&#45;keyword">private</span> <span class="java&#45;object">String</span> city;<p class="paragraph"/>  <span class="java&#45;keyword">public</span> void setName(<span class="java&#45;object">String</span> name) &#123; <span class="java&#45;keyword">this</span>.name = name ; &#125;
 <li>Using the ModelDriven action, we can reference our parameters name, addr, and city.  Also, the Model (Contact) will be pushed onto the ValueStack so we'll have Contact and AddContactAction on the value stack</li>
 <li>In the more recent example, we need to reference our parameters as contact.name, contact.addr, and contact.city.</li>
 </ul>
-<h3 class="heading-1"><a name="Chaining"/><a href="interceptors.html#Chaining" title="Permalink to Chaining"><img src="http://wiki.opensymphony.com/images/permalink.png" alt="" border="0"/></a> ChainingInterceptor
-</h3><p class="paragraph"/>The <b class="bold">ChainingInterceptor</b> populates the Action it is being applied to with the results of the previous action. When actions are chained together, the action being chained FROM is on the ValueStack when the next action is called. This means that when the next ActionProxy is executed, the action that is being chained TO will be placed onto the valuestack, but the old action will also be there, just down one level. This interceptor works by traversing the ValueStack to find the parameters of any objects there and sets them onto the final action.
-<h3 class="heading-1"><a name="DefaultWorkflow"/><a href="interceptors.html#DefaultWorkflow" title="Permalink to DefaultWorkflow"><img src="http://wiki.opensymphony.com/images/permalink.png" alt="" border="0"/></a> DefaultWorkflowInterceptor
-</h3><p class="paragraph"/>The <b class="bold">DefaultWorkflowInterceptor</b> implements the workflow that was found in ActionSupport in WebWork 1.x. These workflow steps are applied before the rest of the Interceptors and the Action are executed, and may short-circuit their execution:
+<h3 class="heading-1"><a name="Chaining"/><a href="interceptors.html#Chaining" title="Permalink to Chaining"><img src="http://wiki.opensymphony.com/images/permalink.png" alt="" border="0"/></a> ChainingInterceptor</h3><p class="paragraph"/>The <b class="bold">ChainingInterceptor</b> populates the Action it is being applied to with the results of the previous action. When actions are chained together, the action being chained FROM is on the ValueStack when the next action is called. This means that when the next ActionProxy is executed, the action that is being chained TO will be placed onto the valuestack, but the old action will also be there, just down one level. This interceptor works by traversing the ValueStack to find the parameters of any objects there and sets them onto the final action.
+<h3 class="heading-1"><a name="DefaultWorkflow"/><a href="interceptors.html#DefaultWorkflow" title="Permalink to DefaultWorkflow"><img src="http://wiki.opensymphony.com/images/permalink.png" alt="" border="0"/></a> DefaultWorkflowInterceptor</h3><p class="paragraph"/>The <b class="bold">DefaultWorkflowInterceptor</b> implements the workflow that was found in ActionSupport in WebWork 1.x. These workflow steps are applied before the rest of the Interceptors and the Action are executed, and may short-circuit their execution:
 <ol>
 <li>If the Action implements <b class="bold">com.opensymphony.xwork.Validateable</b>, the <b class="bold">validate()</b> method is called on it, to allow the Action to execute any validation logic coded into it.</li>
 <li>If the Action implements <b class="bold">com.opensymphony.xwork.ValidationAware</b> the <b class="bold">hasErrors()</b> method is called to check if the Action has any registered error messages (either Action-level or field-level). If the ValidationAware Action has any errors, <b class="bold">Action.INPUT</b> ("input") is returned without executing the rest of the Interceptors or the Action.</li>
 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>

docs/localisation.html

 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>
 
  <div class="snip-attachments"></div>
  
- <h3 class="heading-1">ActionSupport.getText() and LocalizedTextUtil
-</h3><p class="paragraph"/>The implementation of com.opensymphony.xwork.TextProvider in com.opensymphony.xwork.ActionSupport uses com.opensymphony.xwork.util.LocalizedTextUtil to find localized message texts for message keys. LocalizedTextUtil uses a system of defaults for finding resource bundle property files for searching for the message text. If LocalizedTextUtil.findText(Class aClass, String aTextName, Locale locale) is called (or LocalizedTextUtil.findText(Class aClass, String aTextName), which just uses the Locale from ActionContext.getContext.getLocale()), the following search order is used:
-
+ <h3 class="heading-1">ActionSupport.getText() and LocalizedTextUtil</h3><p class="paragraph"/>The implementation of com.opensymphony.xwork.LocaleAware in com.opensymphony.xwork.ActionSupport uses com.opensymphony.xwork.util.LocalizedTextUtil to find localized message texts for message keys. LocalizedTextUtil uses a system of defaults for finding resource bundle property files for searching for the message text. If LocalizedTextUtil.findText(Class aClass, String aTextName, Locale locale) is called (or LocalizedTextUtil.findText(Class aClass, String aTextName), which just uses the Locale from ActionContext.getContext.getLocale()), the following search order is used:
 <ol>
 <li>The class name is used with the call <div class="code"><pre>ResourceBundle.getBundle(aBundleName, locale, <span class="java&#45;object">Thread</span>.currentThread().getContextClassLoader())</pre></div></li>
 <li>If the message text is not found, each parent class of the action is used as above until java.lang.Object is found</li>
 <li>If the message text has still not been found, findDefaultText(aTextName, locale) is called to search the default message bundles</li>
 </ol><p class="paragraph"/>The findDefaultText(aTextName, locale) method searches named resource bundles which have been registered with LocalzedTextUtil in reverse order of their registration (i.e. the first resource bundle name registered is the last to be searched). By default, one default resource bundle name is registered with LocalizedTextUtil for search, "com/opensymphony/xwork/xwork-messages", which is bundled with the jar file to provide system-level message texts.
 
-
   </div>
 </body>
 </html>
 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>
  <div class="snip-attachments"></div>
  
  OGNL is the Object Graph Navigation Language - see <span class="nobr"><img src="http://wiki.opensymphony.com/images/external-link.png" alt="&gt;&gt;" border="0"/><a href="http://www.ognl.org">&#104;ttp://www.ognl.org</a></span> for the full documentation of OGNL. In this document we will only show the additional language features that are provided on top of the base OGNL EL. 
-<h3 class="heading-1">XWork-specific language features
-</h3>
+<h3 class="heading-1">XWork-specific language features</h3>
 The biggest addition that XWork provides on top of OGNL is the support for the ValueStack. While OGNL operates under the assumption there is only one "root", XWork's ValueStack concept requires there be many "roots".<p class="paragraph"/>For example, suppose we are using standard OGNL (not using XWork) and there are two objects in the OgnlContext map: "foo" -&#62; foo and "bar" -&#62; bar and that the foo object is also configured to be the single *root* object. The following code illustrates how OGNL deals with these three situations:<p class="paragraph"/><div class="code"><pre>#foo.blah // returns foo.getBlah()
 #bar.blah // returns bar.getBlah()
 blah      // returns foo.getBlah() because foo is the root</pre></div><p class="paragraph"/>What this means is that OGNL allows many objects in the context, but unless the object you are trying to access is the root, it must be prepended with a namespaces such as @bar. Now let's talk about how XWork is a little different...<p class="paragraph"/>In XWork, the entire ValueStack is the root object in the context. But rather than having your expressions get the object you want from the stack and then get properties from that (ie: peek().blah), XWork has a special OGNL PropertyAccessor that will automatically look at the all entries in the stack (from the top down) until it finds an object with the property you are looking for.<p class="paragraph"/>For example, suppose the stack contains two objects: Animal and Person. Both objects have a "name" property, Animal has a "species" property, and Person has a "salary" property. Animal is on the top of the stack, and Person is below it. The follow code fragments help you get an idea of what is going on here:<p class="paragraph"/><div class="code"><pre>species    // call to animal.getSpecies()
 salary     // call to person.getSalary()
 name       // call to animal.getName() because animal is on the top</pre></div><p class="paragraph"/>In the last example, there was a tie and so the animal's name was returned. Usually this is the desired effect, but sometimes you want the property of a lower-level object. To do this, XWork has added support for indexes on the ValueStack. All you have to do is:<p class="paragraph"/><div class="code"><pre>&#91;0&#93;.name   // call to animal.getName()
 &#91;1&#93;.name   // call to person.getName()</pre></div>
-<h3 class="heading-1">Accessing static properties
-</h3><p class="paragraph"/>OGNL supports accessing static properties as well as static methods. As the OGNL docs point out, you can explicetly call statics by doing the following:<p class="paragraph"/><div class="code"><pre>@some.package.ClassName@FOO_PROPERTY
+<h3 class="heading-1">Accessing static properties</h3><p class="paragraph"/>OGNL supports accessing static properties as well as static methods. As the OGNL docs point out, you can explicetly call statics by doing the following:<p class="paragraph"/><div class="code"><pre>@some.package.ClassName@FOO_PROPERTY
 @some.package.ClassName@someMethod()</pre></div><p class="paragraph"/>However, XWork allows you to avoid having to specify the full package name and call static properties and methods of your action classes using the "vs" prefix:<p class="paragraph"/><div class="code"><pre>@vs@FOO_PROPERTY
 @vs@someMethod()<p class="paragraph"/>@vs1@FOO_PROPERTY
 @vs1@someMethod()<p class="paragraph"/>@vs2@BAR_PROPERTY
 @vs2@someOtherMethod()</pre></div><p class="paragraph"/>The important thing to note here is that if the class name you specify is just "vs", the class for the object on the top of the stack is used. If you specify a number after the "vs" string, an object's class deeper in the stack is used instead.
-<h3 class="heading-1">Differences from the WebWork 1.x EL
-</h3>
-Besides the examples and descriptions given above, there are a few major changes in the EL since WebWork 1.x. The biggest one is that properties are no longer accessed with a forward slash (/) but with a dot (.). Also, rather than using ".." to traverse down the stack, we now use "&#91;n&#93;" where n is some positive number. Lastly, in WebWork 1.x one could access special named objects (the request scope attributes to be exact) by using "@foo", but now special variables are accessed using "#foo". However, it is important to note that "#foo" does NOT access the request attributes. Because XWork is not built only for the web, there is no concept of "request attributes", and thus "#foo" is merely a request to another object in the OgnlContext other than the root.<p class="paragraph"/><table class="wiki-table" cellpadding="0" cellspacing="0" border="0"><tr><th>Old Expression</th><th>New Expression</th></tr><tr class="table-odd"><td>foo/blah</td><td>foo.blah</td></tr><tr class="table-even"><td>foo/someMethod()</td><td>foo.someMethod()</td></tr><tr class="table-odd"><td>../bar/blah</td><td>&#91;1&#93;.bar.blah</td></tr><tr class="table-even"><td>@baz</td><td>not directly supported, but #baz is similar</td></tr><tr class="table-odd"><td>.</td><td>that</td></tr></table>
+<h3 class="heading-1">Differences from the WebWork 1.x EL</h3>
+Besides the examples and descriptions given above, there are a few major changes in the EL since WebWork 1.x. The biggest one is that properties are no longer accessed with a forward slash (/) but with a dot (.). Also, rather than using ".." to traverse down the stack, we now use "&#91;n&#93;" where n is some positive number. Lastly, in WebWork 1.x one could access special named objects (the request scope attributes to be exact) by using "@foo", but now special variables are accessed using "#foo". However, it is important to note that "#foo" does NOT access the request attributes. Because XWork is not built only for the web, there is no concept of "request attributes", and thus "#foo" is merely a request to another object in the OgnlContext other than the root.<p class="paragraph"/><table class="wiki-table" cellpadding="0" cellspacing="0" border="0"><tr><th>Old Expression</th><th>New Expression</th></tr><tr class="table-odd"><td>foo/blah</td><td>foo.blah</td></tr><tr class="table-even"><td>foo/someMethod()</td><td>foo.someMethod()</td></tr><tr class="table-odd"><td>../bar/blah</td><td>&#91;1&#93;.bar.blah</td></tr><tr class="table-even"><td>@baz</td><td>not directly supported, but #baz is similar</td></tr><tr class="table-odd"><td>.</td><td>top or &#91;0&#93;</td></tr></table>
+<h3 class="heading-1">WebWork-specific named objects</h3>
+<table class="wiki-table" cellpadding="0" cellspacing="0" border="0"><tr><th>name</th><th>value</th></tr><tr class="table-odd"><td>parameters&#91;'foo']</td><td>request attribute 'foo'</td></tr><tr class="table-even"><td>request&#91;'foo']</td><td>same as parameters&#91;'foo']</td></tr><tr class="table-odd"><td>session&#91;'foo']</td><td>session attribute 'foo'</td></tr><tr class="table-even"><td>application&#91;'foo']</td><td>ServletContext attributes 'foo'</td></tr></table>
+
   </div>
 </body>
 </html>

docs/rickard.html

 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>

docs/roadmap.html

 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>
  <div class="snip-attachments"></div>
  
  Here is an overview of the general goals of the next generation <a href="http://wiki.opensymphony.com/space/WebWork">WebWork</a>, called <a href="index.html">XWork</a>. Suggestions and feature requests are encouraged to be directed to the <span class="nobr"><img src="http://wiki.opensymphony.com/images/external-link.png" alt="&gt;&gt;" border="0"/><a href="http://lists.sourceforge.net/lists/listinfo/opensymphony-webwork">WebWork mailing list</a></span>, not here. Please feel free to fill this in as much as possible.
-<h3 class="heading-1-1">Core:
-</h3>
+<h3 class="heading-1-1">Core:</h3>
 <ul class="star">
 <li>Completely divorce from dependence on J2EE - <b class="bold">done</b></li>
 <li>Provide additional Dispatchers: e.g. JMSDispatcher and MailDispatcher - <b class="bold">Out of Scope</b></li>
 <li>Fix/standardize logging - <b class="bold">done</b> I think</li>
 <li>Self-reloading config system, detects changes in config files and reloads accordingly - <b class="bold">done</b></li>
 </ul>
-<h3 class="heading-1-1">Documentation:
-</h3>
+<h3 class="heading-1-1">Documentation:</h3>
 <ul class="star">
 <li><a href="documentation.html">XWork Documentation</a></li>
 <li>Jira Xwork Roadmap: <span class="nobr"><img src="http://wiki.opensymphony.com/images/external-link.png" alt="&gt;&gt;" border="0"/><a href="http://jira.opensymphony.com/secure/BrowseProject.jspa?id=10050&amp;report=roadmap">&#104;ttp://jira.opensymphony.com/secure/BrowseProject.jspa?id=10050&amp;report=roadmap</a></span></li>

docs/statement.html

 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>

docs/validation.html

 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>
  <div class="snip-attachments"></div>
  
  The validation framework in XWork is designed to help you apply simple validation rules to your Actions before they are executed. 
-<h3 class="heading-1">Core Concepts
-</h3><p class="paragraph"/>The Validator framework, at its core, takes just an object and a String context name for which to validate that object. This allows you to have different validations for the same class in different contexts. You can define default validations in the class-level validation file (<b class="bold">ClassName-validation.xml</b>), and then define validations which are added on top of these for a specific context (<b class="bold">ClassName-contextName-validation.xml</b>). In the case of Action validation, this context is the Action alias. The validators are applied in the order they are listed in the validation files and error messages are saved into the Object (if it implements ValidationAware).
-<h3 class="heading-1">The ValidationInterceptor
-</h3><p class="paragraph"/>The ValidationInterceptor is an Xwork Interceptor which handles the process of applying validators to an Action before it is executed and allows the Validators to apply any messages to the Action that are required. Bear in mind that even if errors are added due to failed validation, the action will still be executed.
-<h3 class="heading-1">Registering Validators
-</h3><p class="paragraph"/>Validators must be registered with the ValidatorFactory. This may either be done programmatically, using the registerValidator(String name, Class clazz) static method of the ValidatorFactory, or by putting a file name validators.xml in the root of the classpath with a structure like this:<p class="paragraph"/><div class="code"><pre>&#60;validators&#62;
+<h3 class="heading-1">Core Concepts</h3><p class="paragraph"/>The Validator framework, at its core, takes just an object and a String context name for which to validate that object. This allows you to have different validations for the same class in different contexts. You can define default validations in the class-level validation file (<b class="bold">ClassName-validation.xml</b>), and then define validations which are added on top of these for a specific context (<b class="bold">ClassName-contextName-validation.xml</b>). In the case of Action validation, this context is the Action alias. The validators are applied in the order they are listed in the validation files and error messages are saved into the Object (if it implements ValidationAware).
+<h3 class="heading-1">The ValidationInterceptor</h3><p class="paragraph"/>The ValidationInterceptor is an Xwork Interceptor which handles the process of applying validators to an Action before it is executed and allows the Validators to apply any messages to the Action that are required. Bear in mind that even if errors are added due to failed validation, the action will still be executed.
+<h3 class="heading-1">Registering Validators</h3><p class="paragraph"/>Validators must be registered with the ValidatorFactory. This may either be done programmatically, using the registerValidator(String name, Class clazz) static method of the ValidatorFactory, or by putting a file name validators.xml in the root of the classpath with a structure like this:<p class="paragraph"/><div class="code"><pre>&#60;validators&#62;
     &#60;validator name=<span class="xml&#45;quote">"required"</class>
         class=<span class="xml&#45;quote">"com.opensymphony.xwork.validator.validators.RequiredFieldValidator"</class>/&#62;
     &#60;validator name=<span class="xml&#45;quote">"requiredstring"</class>
     &#60;validator name=<span class="xml&#45;quote">"expression"</class> 
         class=<span class="xml&#45;quote">"com.opensymphony.xwork.validator.validators.ExpressionValidator"</class>/&#62;
 &#60;/validators&#62;</pre></div>
-<h3 class="heading-1">Turning on Validation
-</h3><p class="paragraph"/>All that is required to enable validation for an Action is to put the ValidationInterceptor in the interceptor refs of the action (see <a href="configuration.html">Xwork Configuration</a>) like so:<p class="paragraph"/><div class="code"><pre>&#60;interceptor name=<span class="xml&#45;quote">"validator"</class> class=<span class="xml&#45;quote">"com.opensymphony.xwork.validator.ValidationInterceptor"</class>/&#62;</pre></div><p class="paragraph"/>Then create a file named <b class="bold">ActionName-validation.xml</b> in the same package as the Action class file. You may also create alias specific validators which add to the Action class specific validators defined in the <b class="bold">ActionName-validation.xml</b> by creating another file in the same directory name <b class="bold">ActionName-aliasname-validation.xml</b>, where <b class="bold">ActionName</b> is the name of the class, and <b class="bold">aliasname</b> is the name of the action alias defined in the <b class="bold">xwork.xml</b> configuration for this Action. The framework will also search up the inheritance tree of the action to find default validations for parent classes of the Action, just like the <a href="localisation.html">Localization with XWork</a> framework does when finding messages.<p class="paragraph"/>In this way, you may define some default interceptors for all of the alias's of a class, and then define alias specific validators in the <b class="bold">ActionName-alias-validation.xml</b>.
-<h3 class="heading-1">Defining validation rules in a validation.xml
-</h3><p class="paragraph"/>Here is an example validator.xml, SimpleAction-validation.xml, from the Xwork tests:<p class="paragraph"/><div class="code"><pre>&#60;!DOCTYPE validators PUBLIC <span class="xml&#45;quote">"&#45;//OpenSymphony Group//XWork Validator 1.0//EN"</class>
+<h3 class="heading-1">Turning on Validation</h3><p class="paragraph"/>All that is required to enable validation for an Action is to put the ValidationInterceptor in the interceptor refs of the action (see <a href="configuration.html">Xwork Configuration</a>) like so:<p class="paragraph"/><div class="code"><pre>&#60;interceptor name=<span class="xml&#45;quote">"validator"</class> class=<span class="xml&#45;quote">"com.opensymphony.xwork.validator.ValidationInterceptor"</class>/&#62;</pre></div><p class="paragraph"/>Then create a file named <b class="bold">ActionName-validation.xml</b> in the same package as the Action class file. You may also create alias specific validators which add to the Action class specific validators defined in the <b class="bold">ActionName-validation.xml</b> by creating another file in the same directory name <b class="bold">ActionName-aliasname-validation.xml</b>, where <b class="bold">ActionName</b> is the name of the class, and <b class="bold">aliasname</b> is the name of the action alias defined in the <b class="bold">xwork.xml</b> configuration for this Action. The framework will also search up the inheritance tree of the action to find default validations for parent classes of the Action, just like the <a href="localisation.html">Localization with XWork</a> framework does when finding messages.<p class="paragraph"/>In this way, you may define some default interceptors for all of the alias's of a class, and then define alias specific validators in the <b class="bold">ActionName-alias-validation.xml</b>.
+<h3 class="heading-1">Defining validation rules in a validation.xml</h3><p class="paragraph"/>Here is an example validator.xml, SimpleAction-validation.xml, from the Xwork tests:<p class="paragraph"/><div class="code"><pre>&#60;!DOCTYPE validators PUBLIC <span class="xml&#45;quote">"&#45;//OpenSymphony Group//XWork Validator 1.0//EN"</class>
         <span class="xml&#45;quote">"http://www.opensymphony.com/xwork/xwork&#45;validator&#45;1.0.dtd"</class>&#62;
 &#60;validators&#62;
     &#60;field name=<span class="xml&#45;quote">"bar"</class>&#62;
         &#60;message&#62;Foo must be greater than Bar. Foo = $&#123;foo&#125;, Bar = $&#123;bar&#125;.&#60;/message&#62;
     &#60;/validator&#62;
 &#60;/validators&#62;</pre></div><p class="paragraph"/>Here we can see the configuration of validators for the SimpleAction class. Validators (and field-validators) must have a "type" attribute, which refers to a name of an Validator registered with the ValidatorFactory as above. Validator elements may also have &#60;param&#62; elements with name and value attributes to set arbitrary parameters into the Validator instance. See below for discussion of the message element.
-<h3 class="heading-1-1">Validator vs. Field-Validator
-</h3><p class="paragraph"/>Field-Validator elements inside &#60;field&#62; elements are basically the same as Validator elements, except that they inherit a parameter with name "fieldName" and with a value of the field name set in the enclosing field element.<p class="paragraph"/>The reason for the field-&#62;field-validator structure is that it is more clear to group the validators for a particular field under one field element, and because the fieldName param would otherwise always have to be set for field validators.<p class="paragraph"/>That said, it's perfectly legal to only use validator elements without the field elements and set the fieldName parameter for each of them.
-<h3 class="heading-1-1">Message Element
-</h3><p class="paragraph"/>Each Validator or Field-Validator element must define one message element inside the validator element body. The message element has 1 attributes, key which is not required. The body of the message tag is taken as the default message which should be added to the Action if the validator fails.<p class="paragraph"/>Key gives a message key to look up in the Action's ResourceBundles using getText() from LocaleAware if the Action implements that interface (as ActionSupport does). This provides for Localized messages based on the Locale of the user making the request (or whatever Locale you've set into the LocaleAware Action).<p class="paragraph"/>After either retrieving the message from the ResourceBundle using the Key value, or using the Default message, the current Validator is pushed onto the ValueStack, then the message is parsed for &#36;&#123;...&#125; sections which are replaced with the evaluated value of the string between the &#36;&#123; and &#125;. This allows you to parameterize your messages with values from the Validator, the Action, or both. Here is an example of a parameterized message:<p class="paragraph"/><div class="code"><pre>bar must be between &#36;&#123;min&#125; and &#36;&#123;max&#125;, current value is &#36;&#123;bar&#125;.</pre></div><p class="paragraph"/>This will pull the min and max parameters from the IntRangeFieldValidator and the value of bar from the Action.
-<h3 class="heading-1">Building a Validator
-</h3><p class="paragraph"/>Validators implement the <b class="bold">com.opensymphony.xwork.validator.Validator</b> interface<p class="paragraph"/><div class="code"><pre><span class="java&#45;keyword">public</span> <span class="java&#45;keyword">interface</span> Validator &#123;
+<h3 class="heading-1-1">Validator vs. Field-Validator</h3><p class="paragraph"/>Field-Validator elements inside &#60;field&#62; elements are basically the same as Validator elements, except that they inherit a parameter with name "fieldName" and with a value of the field name set in the enclosing field element.<p class="paragraph"/>The reason for the field-&#62;field-validator structure is that it is more clear to group the validators for a particular field under one field element, and because the fieldName param would otherwise always have to be set for field validators.<p class="paragraph"/>That said, it's perfectly legal to only use validator elements without the field elements and set the fieldName parameter for each of them.
+<h3 class="heading-1-1">Message Element</h3><p class="paragraph"/>Each Validator or Field-Validator element must define one message element inside the validator element body. The message element has 1 attributes, key which is not required. The body of the message tag is taken as the default message which should be added to the Action if the validator fails.<p class="paragraph"/>Key gives a message key to look up in the Action's ResourceBundles using getText() from LocaleAware if the Action implements that interface (as ActionSupport does). This provides for Localized messages based on the Locale of the user making the request (or whatever Locale you've set into the LocaleAware Action).<p class="paragraph"/>After either retrieving the message from the ResourceBundle using the Key value, or using the Default message, the current Validator is pushed onto the ValueStack, then the message is parsed for &#36;&#123;...&#125; sections which are replaced with the evaluated value of the string between the &#36;&#123; and &#125;. This allows you to parameterize your messages with values from the Validator, the Action, or both. Here is an example of a parameterized message:<p class="paragraph"/><div class="code"><pre>bar must be between &#36;&#123;min&#125; and &#36;&#123;max&#125;, current value is &#36;&#123;bar&#125;.</pre></div><p class="paragraph"/>This will pull the min and max parameters from the IntRangeFieldValidator and the value of bar from the Action.
+<h3 class="heading-1">Building a Validator</h3><p class="paragraph"/>Validators implement the <b class="bold">com.opensymphony.xwork.validator.Validator</b> interface<p class="paragraph"/><div class="code"><pre><span class="java&#45;keyword">public</span> <span class="java&#45;keyword">interface</span> Validator &#123;
     void setDefaultMessage(<span class="java&#45;object">String</span> message);<p class="paragraph"/>    <span class="java&#45;object">String</span> getDefaultMessage();<p class="paragraph"/>    <span class="java&#45;object">String</span> getMessage(<span class="java&#45;object">Object</span> object);<p class="paragraph"/>    void setMessageKey(<span class="java&#45;object">String</span> key);<p class="paragraph"/>    <span class="java&#45;object">String</span> getMessageKey();<p class="paragraph"/>    /&#42;&#42;
      &#42; This method will be called before validate with a non&#45;<span class="java&#45;keyword">null</span> 
      &#42; ValidatorContext.
      &#42; @<span class="java&#45;keyword">return</span> the field name to be validated
      &#42;/
     <span class="java&#45;object">String</span> getFieldName();<p class="paragraph"/>&#125;</pre></div><p class="paragraph"/>Validators and FieldValidators can extend base classes <b class="bold">com.opensymphony.xwork.validator.validators.ValidatorSupport</b> and <b class="bold">com.opensymphony.xwork.validator.validators.FieldValidatorSupport</b> to get the base message behavior, and will only need to implement validate(Action action).<p class="paragraph"/>The Support classes provide the functionality to use the message key and default message to get the localied message body and the parsing of the message body to provide for parameterized messages. Implementations of the Validator Interface which do not extend the Support base classes should provide this functionality as well for consistency.<p class="paragraph"/>The <b class="bold">ValidatorContext</b> set into the Validator is an interface which extends both <b class="bold">ValidationAware</b> and <b class="bold">LocaleAware</b> and is used for looking up message texts and settting errors. When validators are called from the ValidationInterceptor, a DelegatingValidatorContext is created which delegates these calls to the Action if it implements these interfaces. If the Action does not implement LocaleAware, a LocaleAwareSupport instance is created which uses the Action's class to look up resource bundle texts, if available. If the action does not implement ValidationAware, an implementation which simply logs the validation errors is created and delegated to. When calling the validation framework from outside the ValidationInterceptor, any ValidatorContext implementation can be passed in.<p class="paragraph"/>Validator classes may define any number of properties using the usual getX() setX() naming convention and have those properties set using &#60;param name="x"&#62;foo&#60;/param&#62; elements below the &#60;validator&#62; element. The values of these properties may then be used in the validate() method to parameterize the validation. Validators which extend the Support classes may also use the<p class="paragraph"/>Object getFieldValue(String name, Action action) method to get the field value of a named property from an Action.
-<h3 class="heading-1">Using the Expression Validator
-</h3><p class="paragraph"/>The Expression validator extends the ValidatorSupport base class and has one parameter which should be set using &#60;param name="expression"&#62; any valid ognl expression which returns a boolean&#60;/param&#62;. The expression will be evaluated against the ValueStack, allowing you to use any properties of the Action in comparisons, etc.<p class="paragraph"/>This allows for very powerful cross-property validation expressions. Here is a simple example of the ExpressionValidator in a configuration:<p class="paragraph"/><div class="code"><pre>&#60;validator type=<span class="xml&#45;quote">"expression"</class>&#62;
+<h3 class="heading-1">Using the Expression Validator</h3><p class="paragraph"/>The Expression validator extends the ValidatorSupport base class and has one parameter which should be set using &#60;param name="expression"&#62; any valid ognl expression which returns a boolean&#60;/param&#62;. The expression will be evaluated against the ValueStack, allowing you to use any properties of the Action in comparisons, etc.<p class="paragraph"/>This allows for very powerful cross-property validation expressions. Here is a simple example of the ExpressionValidator in a configuration:<p class="paragraph"/><div class="code"><pre>&#60;validator type=<span class="xml&#45;quote">"expression"</class>&#62;
         &#60;param name=<span class="xml&#45;quote">"expression"</class>&#62;foo &#62; bar&#60;/param&#62;
         &#60;message default=<span class="xml&#45;quote">"Foo must be greater than Bar. Foo = $&#123;foo&#125;, Bar = $&#123;bar&#125;."</class>/&#62;
 &#60;/validator&#62;</pre></div>

docs/validationexample.html

 <html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-  <title>OpenSymphony Wiki :: Xwork Documentation</title>
+  <title>OpenSymphony Wiki (Offline Version) :: Xwork Documentation</title>
   <link type="text/css" href="main.css" rel="STYLESHEET"/>
 </head>
 <body>
  <div class="snip-attachments"></div>
  
  Included in the <a href="http://wiki.opensymphony.com/space/WebWork2">WebWork2</a> example war file is an example of using the <a href="validation.html">Xwork Validation Framework</a> in WebWork2. This example consists of three links which all use the same Action Class and view pages (Velocity).
-<h3 class="heading-1">The sources
-</h3><p class="paragraph"/>First, I had to add the <b class="bold">validators.xml</b> file to the root of the source tree for the example app
+<h3 class="heading-1">The sources</h3><p class="paragraph"/>First, I had to add the <b class="bold">validators.xml</b> file to the root of the source tree for the example app
 <div class="code"><pre>&#60;validators&#62;
     &#60;validator name=<span class="xml&#45;quote">"required"</class> class=<span class="xml&#45;quote">"com.opensymphony.xwork.validator.validators.RequiredFieldValidator"</class>/&#62;
     &#60;validator name=<span class="xml&#45;quote">"requiredstring"</class> class=<span class="xml&#45;quote">"com.opensymphony.xwork.validator.validators.RequiredStringValidator"</class>/&#62;
 Input was valid!
 &#60;/body&#62;
 &#60;/html&#62;</pre></div><p class="paragraph"/>We'll look at any other example-specific configuration files as we get to them.
-<h3 class="heading-1"><a name="BasicValidation"/><a href="validationexample.html#BasicValidation" title="Permalink to BasicValidation"><img src="http://wiki.opensymphony.com/images/permalink.png" alt="" border="0"/></a> Basic Validation
-</h3><p class="paragraph"/>
+<h3 class="heading-1"><a name="BasicValidation"/><a href="validationexample.html#BasicValidation" title="Permalink to BasicValidation"><img src="http://wiki.opensymphony.com/images/permalink.png" alt="" border="0"/></a> Basic Validation</h3><p class="paragraph"/>
 The BasicValidation example is defined in the example <b class="bold">xwork.xml</b> file like this
 <div class="code"><pre>&#60;action name=<span class="xml&#45;quote">"basicValidation"</class> class=<span class="xml&#45;quote">"com.opensymphony.webwork.example.ValidatedAction"</class>&#62;
             &#60;interceptor&#45;ref name=<span class="xml&#45;quote">"validationWorkflowStack"</class>/&#62;<p class="paragraph"/>            &#60;result name=<span class="xml&#45;quote">"success"</class> type=<span class="xml&#45;quote">"dispatcher"</class>&#62;valid.vm&#60;/result&#62;
             &#60;result name=<span class="xml&#45;quote">"input"</class> type=<span class="xml&#45;quote">"dispatcher"</class>&#62;validationForm.vm&#60;/result&#62;
             &#60;result name=<span class="xml&#45;quote">"error"</class> type=<span class="xml&#45;quote">"dispatcher"</class>&#62;validationForm.vm&#60;/result&#62;
         &#60;/action&#62;</pre></div><p class="paragraph"/>The <b class="bold">interceptor-ref</b> here, to <b class="bold">"validationWorkflowStack"</b>, is defined in webwork-default.xml (see <a href="http://wiki.opensymphony.com/space/Using+webwork-default.xml">Using webwork-default.xml</a>) and provides the parameter interceptors as well as the ValidationInterceptor (see <a href="validation.html">Xwork Validation Framework</a> and the DefaultWorkFlowInterceptor (see <a href="interceptors.html#DefaultWorkflow">Xwork Interceptors#DefaultWorkflow</a>). All of the parameters from the configuration file (there are none in this case) followed by the parameters from the request will be set onto the Action. Next, the validations will be run, and finally the DefaultWorkflow will be applied (see <a href="interceptors.html#DefaultWorkflow">Xwork Interceptors#DefaultWorkflow</a>).<p class="paragraph"/>This example is very simple, and the ValidatedAction-validation.xml file is the only set of Validations which will be applied. This means that the only validation done is that you enter some text for the name field. 
-<h3 class="heading-1"><a name="VisitorValidation"/><a href="validationexample.html#VisitorValidation" title="Permalink to VisitorValidation"><img src="http://wiki.opensymphony.com/images/permalink.png" alt="" border="0"/></a> Visitor Validation Example
-</h3><p class="paragraph"/>The <b class="bold">ValidatedAction</b> holds a reference to a plain Java bean, <b class="bold">ValidatedBean</b>:
+<h3 class="heading-1"><a name="VisitorValidation"/><a href="validationexample.html#VisitorValidation" title="Permalink to VisitorValidation"><img src="http://wiki.opensymphony.com/images/permalink.png" alt="" border="0"/></a> Visitor Validation Example</h3><p class="paragraph"/>The <b class="bold">ValidatedAction</b> holds a reference to a plain Java bean, <b class="bold">ValidatedBean</b>:
 <div class="code"><pre><span class="java&#45;keyword">package</span> com.opensymphony.webwork.example;<p class="paragraph"/><span class="java&#45;keyword">import</span> java.util.Date;<p class="paragraph"/>/&#42;&#42;
  &#42; ValidatedBean
  &#42; @author Jason Carreira
 invalid.text=You must enter some text.
 invalid.number=You must enter a number between $&#123;min&#125; and $&#123;max&#125;.
 invalid.total=The total of number and number2 must be less than $&#123;@com.opensymphony.webwork.example.ValidatedBean@MAX_TOTAL&#125;.</pre></div><p class="paragraph"/>These messages will be used for any errors added for the <b class="bold">ValidatedBean</b> using a message key. As you can see from the body of the messages, they can be parameterized with properties from the Bean, the Interceptor, and the Action (and they will be searched in that order). There is also an example of using a Static field <b class="bold">${@com.opensymphony.webwork.example.ValidatedBean@MAX_TOTAL}</b>.<p class="paragraph"/>The <b class="bold">ValidatedBean-visitorValidation-validation.xml</b> file would define validations specific for the <b class="bold">visitorValidation</b> validation context, but it is not there, so it is ignored.
-<h3 class="heading-1"><a name="Expression"/><a href="validationexample.html#Expression" title="Permalink to Expression"><img src="http://wiki.opensymphony.com/images/permalink.png" alt="" border="0"/></a> Visitor Validation with the Expression Validator
-</h3><p class="paragraph"/>The final example shows a similar setup to the previous visitor validation example. The <b class="bold">xwork.xml</b> configuration for this example is very similar to the <b class="bold">visitorValidation</b> example:
+<h3 class="heading-1"><a name="Expression"/><a href="validationexample.html#Expression" title="Permalink to Expression"><img src="http://wiki.opensymphony.com/images/permalink.png" alt="" border="0"/></a> Visitor Validation with the Expression Validator</h3><p class="paragraph"/>The final example shows a similar setup to the previous visitor validation example. The <b class="bold">xwork.xml</b> configuration for this example is very similar to the <b class="bold">visitorValidation</b> example:
 <div class="code"><pre>&#60;action name=<span class="xml&#45;quote">"expressionValidation"</class> class=<span class="xml&#45;quote">"com.opensymphony.webwork.example.ValidatedAction"</class>&#62;
             &#60;interceptor&#45;ref name=<span class="xml&#45;quote">"validationWorkflowStack"</class>/&#62;
             &#60;param name=<span class="xml&#45;quote">"validationAction"</class>&#62;expressionValidation.action&#60;/param&#62;
     &#60;/validator&#62;
 &#60;/validators&#62;</pre></div>
 This adds an object-level (as opposed to field-level) ExpressionValidator which checks the total of the number and number2 fields against a static constant, and adds an error message if the total is more than the constant. 
-<h3 class="heading-1"><a name="ErrorMessages"/><a href="validationexample.html#ErrorMessages" title="Permalink to ErrorMessages"><img src="http://wiki.opensymphony.com/images/permalink.png" alt="" border="0"/></a> A note about error messages with the VisitorFieldValidator
-</h3><p class="paragraph"/>With the VisitorFieldValidator, message field names are appended with the field name of the field in the Action. In this case, the fields "<b class="bold">text</b>", "<b class="bold">date</b>", and "<b class="bold">number</b>" in the <b class="bold">ValidatedBean</b> would be added as field error messages to the Action with field names "<b class="bold">bean.text</b>", "<b class="bold">bean.date</b>", and "<b class="bold">bean.number</b>". The error messages added for the object-level ExpressionValidator applied in the last example will be added as field-level errors to the Action with the name "<b class="bold">bean</b>".
+<h3 class="heading-1"><a name="ErrorMessages"/><a href="validationexample.html#ErrorMessages" title="Permalink to ErrorMessages"><img src="http://wiki.opensymphony.com/images/permalink.png" alt="" border="0"/></a> A note about error messages with the VisitorFieldValidator</h3><p class="paragraph"/>With the VisitorFieldValidator, message field names are appended with the field name of the field in the Action. In this case, the fields "<b class="bold">text</b>", "<b class="bold">date</b>", and "<b class="bold">number</b>" in the <b class="bold">ValidatedBean</b> would be added as field error messages to the Action with field names "<b class="bold">bean.text</b>", "<b class="bold">bean.date</b>", and "<b class="bold">bean.number</b>". The error messages added for the object-level ExpressionValidator applied in the last example will be added as field-level errors to the Action with the name "<b class="bold">bean</b>".
 
   </div>
 </body>
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.