Repository: struts-site Updated Branches: refs/heads/master 116c7b012 -> b4f6a844f
http://git-wip-us.apache.org/repos/asf/struts-site/blob/b4f6a844/source/core-developers/type-conversion.md ---------------------------------------------------------------------- diff --git a/source/core-developers/type-conversion.md b/source/core-developers/type-conversion.md index 6fbe165..5cc568c 100644 --- a/source/core-developers/type-conversion.md +++ b/source/core-developers/type-conversion.md @@ -5,51 +5,54 @@ title: Type Conversion # Type Conversion -Routine type conversion in the framework is transparent\. Generally, all you need to do is ensure that HTML inputs have names that can be used in _OGNL_ expressions\. (HTML inputs are form elements and other GET/POST parameters\.) +Routine type conversion in the framework is transparent. Generally, all you need to do is ensure that HTML inputs have +names that can be used in [OGNL](ognl.html) expressions. (HTML inputs are form elements and other GET/POST parameters.) -####Built in Type Conversion Support#### +## Built in Type Conversion Support -Type Conversion is implemented by XWork\. +Type Conversion is implemented by XWork. XWork will automatically handle the most common type conversion for you. +This includes support for converting to and from Strings for each of the following: +- String +- boolean / Boolean +- char / Character +- int / Integer, float / Float, long / Long, double / Double +- dates - uses the SHORT format for the Locale associated with the current request +- arrays - assuming the individual strings can be coverted to the individual items +- collections - if not object type can be determined, it is assumed to be a String and a new ArrayList is created + > Note that with arrays the type conversion will defer to the type of the array elements and try to convert each item + > individually. As with any other type conversion, if the conversion can't be performed the standard type conversion + > error reporting is used to indicate a problem occurred while processing the type conversion. +- Enumerations +- BigDecimal and BigInteger -~~~~~~~ -{snippet:id=javadoc|javadoc=true|url=com.opensymphony.xwork2.conversion.impl.XWorkBasicConverter} -~~~~~~~ +## Relationship to Parameter Names -+ Enumerations - -+ BigDecimal and BigInteger - -####Relationship to Parameter Names#### - -There is no need to capture form values using intermediate Strings and primitives\. Instead, the framework can read from and write to properties of objects addressed via OGNL expressions and perform the appropriate type conversion for you\. +There is no need to capture form values using intermediate Strings and primitives. Instead, the framework can read from +and write to properties of objects addressed via OGNL expressions and perform the appropriate type conversion for you. Here are some tips for leveraging the framework's type conversion capabilities: -+ Use OGNL expressions \- the framework will automatically take care of creating the actual objects for you\. - -+ Use JavaBeans\! The framework can only create objects that obey the JavaBean specification, provide no\-arg constructions and include getters and setters where appropriate\. - -+ Remember that _person\.name_ will call **getPerson()\.setName()**\. If the framework creates the Person object for you, it remember that a - -~~~~~~~ -setPerson -~~~~~~~ - method must also exist\. - -+ The framework will not instantiate an object if an instance already exists\. The PrepareInterceptor or action's constructor can be used to create target objects before type conversion\. - -+ For lists and maps, use index notation, such as _people\[0\]\.name_ or _friends\['patrick'\]\.name_ \. Often these HTML form elements are being rendered inside a loop\. For _JSP Tags_ , use the iterator tag's status attribute\. For _FreeMarker Tags_ , use the special property \$\{foo\_index\}\[\]\. - -+ For multiple select boxes, it isn't possible to use index notation to name each individual item\. Instead, name your element _people\.name_ and the framework will understand that it should create a new Person object for each selected item and set its name accordingly\. - -####Creating a Type Converter#### - -Create a type converter by extending StrutsTypeConverter\. The Converter's role is to convert a String to an Object and an Object to a String\. - - -~~~~~~~ - +- Use OGNL expressions - the framework will automatically take care of creating the actual objects for you. +- Use JavaBeans - The framework can only create objects that obey the JavaBean specification, provide no-arg constructions + and include getters and setters where appropriate. + > Remember that `person.name` will call `getPerson().setName()`. If the framework creates the Person object for you, + > it remember that a `setPerson` method must also exist. +- The framework will not instantiate an object if an instance already exists. The `PrepareInterceptor` or action's + constructor can be used to create target objects before type conversion. +- For lists and maps, use index notation, such as `people[0].name` or `friends['patrick'].name`. Often these HTML form + elements are being rendered inside a loop. For [JSP Tags](../tags-guide/), use the iterator tag's status attribute. + For [FreeMarker Tags](freemarker-support.html), use the special property `${foo_index}[]`. +- For multiple select boxes, it isn't possible to use index notation to name each individual item. Instead, name your + element `people.name` and the framework will understand that it should create a new Person object for each selected + item and set its name accordingly. + +## Creating a Type Converter + +Create a type converter by extending `StrutsTypeConverter`. The Converter's role is to convert a String to an Object +and an Object to a String. + +```java public class MyConverter extends StrutsTypeConverter { public Object convertFromString(Map context, String[] values, Class toClass) { ..... @@ -59,149 +62,173 @@ Create a type converter by extending StrutsTypeConverter\. The Converter's role ..... } } +``` -~~~~~~~ - - - -| To allow Struts to recognize that a conversion error has occurred, the converter class needs to throw XWorkException or preferably TypeConversionException\. - -| +> To allow Struts to recognize that a conversion error has occurred, the converter class needs to throw XWorkException +> or preferably TypeConversionException. -####Applying a Type Converter to an Action#### +## Applying a Type Converter to an Action -Create a file called 'ActionClassName\-conversion\.properties' in the same location of the classpath as the Action class itself resides\. - -Eg\. if the action class name is MyAction, the action\-level conversion properties file should be named 'MyAction\-conversion\.properties'\. If the action's package is com\.myapp\.actions the conversion file should also be in the classpath at /com/myapp/actions/\. +Create a file called `ActionClassName-conversion.properties` in the same location of the classpath as the Action class +itself resides. Eg. if the action class name is MyAction, the action-level conversion properties file should be +named `MyAction-conversion.properties`. If the action's package is `com.myapp.actions` the conversion file should +also be in the classpath at `/com/myapp/actions/`. Within the conversion file, name the action's property and the Converter to apply to it: - -~~~~~~~ - +``` # syntax: <propertyName> = <converterClassName> point = com.acme.PointConverter person.phoneNumber = com.acme.PhoneNumberConverter +``` -~~~~~~~ - -Type conversion can also be specified via [Annotations](#PAGE_14017) within the action\. - -####Applying a Type Converter to a bean or model#### +Type conversion can also be specified via [Annotations](annotations.html) within the action. -When getting or setting the property of a bean, the framework will look for "classname\-conversion\.properties" in the same location of the **classpath** as the target bean\. This is the same mechanism as used for actions\. +## Applying a Type Converter to a bean or model -**Example:** A custom converter is required for the Amount property of a Measurement bean\. The Measurement class cannot be modified as its located within one of the application's dependencies\. The action using Measurement implements ModelDriven\<Measurement\> so it cannot apply converters to the properties directly\. -**Solution:** The conversion file needs to be in the same location of the classpath as Measurement\. Create a directory in your source or resources tree matching the package of Measurement and place the converters file there\. +When getting or setting the property of a bean, the framework will look for `classname-conversion.properties` in +the same location of the **classpath** as the target bean. This is the same mechanism as used for actions. -eg\. for com\.acme\.measurements\.Measurement, create a file in the application source/resources at /com/acme/measurements/Measurement\-conversion\.properties: +**Example:** +A custom converter is required for the Amount property of a Measurement bean. The Measurement class cannot be modified +as its located within one of the application's dependencies. The action using Measurement implements +`ModelDriven<Measurement>` so it cannot apply converters to the properties directly. +**Solution:** +The conversion file needs to be in the same location of the classpath as Measurement. Create a directory in your source +or resources tree matching the package of Measurement and place the converters file there. +eg. for `com.acme.measurements.Measurement`, create a file in the application source/resources +at `/com/acme/measurements/Measurement-conversion.properties`: -~~~~~~~ - +``` # syntax: <propertyName>=<converterClassName> amount=com.acme.converters.MyCustomBigDecimalConverter +``` -~~~~~~~ - -####Applying a Type Converter for an application#### - -Application\-wide converters can be specified in a file called xwork\-conversion\.properties located in the root of the classpath\. - +## Applying a Type Converter for an application -~~~~~~~ +Application-wide converters can be specified in a file called `xwork-conversion.properties` located in the root of the classpath. +``` # syntax: <type> = <converterClassName> java.math.BigDecimal = com.acme.MyBigDecimalConverter +``` -~~~~~~~ +## A Simple Example -####A Simple Example#### +Type conversion is great for situations where you need to turn a String in to a more complex object. Because the web +is type-agnostic (everything is a string in HTTP), Struts 2's type conversion features are very useful. For instance, +if you were prompting a user to enter in coordinates in the form of a string (such as "3, 22"), you could have +Struts 2 do the conversion both from String to Point and from Point to String. +Using this "point" example, if your action (or another compound object in which you are setting properties on) +has a corresponding ClassName-conversion.properties file, Struts 2 will use the configured type converters for +conversion to and from strings. So turning "3, 22" in to new Point(3, 22) is done by merely adding the following +entry to <b>ClassName-conversion.properties</b> (Note that the PointConverter should impl the TypeConverter +interface): +``` +point = com.acme.PointConverter</b></p> +``` -~~~~~~~ -{snippet:id=javadoc|javadoc=true|url=com.opensymphony.xwork2.conversion.impl.XWorkConverter} -~~~~~~~ +Your type converter should be sure to check what class type it is being requested to convert. Because it is used +for both to and from strings, you will need to split the conversion method in to two parts: one that turns Strings in +to Points, and one that turns Points in to Strings. -\{snippet:id=i18n\-note|javadoc=true|url=com\.opensymphony\.xwork2\.conversion\.impl\.XWorkConverter\} +After this is done, you can now reference your point (using <s:property value="point"/> in JSP or ${point} +in FreeMarker) and it will be printed as "3, 22" again. As such, if you submit this back to an action, it will be +converted back to a Point once again. -The framework ships with a base helper class that simplifies converting to and from Strings, +In some situations you may wish to apply a type converter globally. This can be done by editing the file +`xwork-conversion.properties` in the root of your class path (typically WEB-INF/classes) and providing a +property in the form of the class name of the object you wish to convert on the left hand side and the class name of +the type converter on the right hand side. For example, providing a type converter for all Point objects would mean +adding the following entry: -~~~~~~~ -org.apache.struts2.util.StrutsTypeConverter -~~~~~~~ -\. The helper class makes it easy to write type converters that handle converting objects to Strings as well as from Strings\. +``` +com.acme.Point = com.acme.PointConverter +``` -From the JavaDocs: +Type conversion should not be used as a substitute for i18n. It is not recommended to use this feature to print out +properly formatted dates. Rather, you should use the i18n features of Struts 2 (and consult the JavaDocs for JDK's +MessageFormat object) to see how a properly formatted date should be displayed. +The framework ships with a base helper class that simplifies converting to and from Strings, +`org.apache.struts2.util.StrutsTypeConverter`. The helper class makes it easy to write type converters that handle +converting objects to Strings as well as from Strings. -~~~~~~~ -{snippet:id=javadoc|javadoc=true|url=org.apache.struts2.util.StrutsTypeConverter} -~~~~~~~ +Base class for type converters used in Struts. This class provides two abstract methods that are used to convert +both to and from strings -- the critical functionality that is core to Struts's type conversion system. -####Advanced Type Conversion#### +Type converters do not have to use this class. It is merely a helper base class, although it is recommended that +you use this class as it provides the common type conversion contract required for all web-based type conversion. -The framework also handles advanced type conversion cases, like null property handling and converting values in Maps and Collections, and type conversion error handling\. +There's a hook (fall back method) called `performFallbackConversion` of which could be used to perform some fallback +conversion if `convertValue` method of this failed. By default it just ask its super class (Ognl's `DefaultTypeConverter`) +to do the conversion. -#####Null Property Handling##### +To allow the framework to recognize that a conversion error has occurred, throw an XWorkException or preferable a TypeConversionException. -Null property handling will automatically create objects where null references are found\. +## Advanced Type Conversion +The framework also handles advanced type conversion cases, like null property handling and converting values in Maps +and Collections, and type conversion error handling. -~~~~~~~ -{snippet:id=javadoc|javadoc=true|url=com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler} -~~~~~~~ +### Null Property Handling +Null property handling will automatically create objects where null references are found. -~~~~~~~ -{snippet:id=example|javadoc=true|url=com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler} -~~~~~~~ +Provided that the key `ReflectionContextState#CREATE_NULL_OBJECTS` is in the action context with a value of true +(this key is set only during the execution of the `com.opensymphony.xwork2.interceptor.ParametersInterceptor`), +OGNL expressions that have caused a `NullPointerException` will be temporarily stopped for evaluation while the system +automatically tries to solve the null references by automatically creating the object. -#####Collection and Map Support##### +The following rules are used when handling null references: -Collection and Map support provides intelligent null handling and type conversion for Java Collections\. +- If the property is declared _exactly_ as a `Collection` or `List`, then an `ArrayList` shall be returned and assigned + to the null references +- If the property is declared as a `Map`, then a `HashMap` will be returned and assigned to the null references +- If the null property is a simple bean with a no-arg constructor, it will simply be created using + the `ObjectFactory#buildBean(java.lang.Class, java.util.Map)` method -The framework supports ways to discover the object type for elements in a collection\. The discover is made via an _ObjectTypeDeterminer_ \. A default implementation is provided with the framework\. The Javadocs explain how Map and Collection support is discovered in the +For example, if a form element has a text field named `person.name` and the expression `person` evaluates to null, then +this class will be invoked. Because the `person` expression evaluates to a `Person` class, a new Person is created +and assigned to the null reference. Finally, the name is set on that object and the overall effect is that the system +automatically created a `Person` object for you, set it by calling `setUsers()` and then finally called +`getUsers().setName()` as you would typically expect. -~~~~~~~ -DefaultObjectTypeDeterminer -~~~~~~~ -\. +## Collection and Map Support +Collection and Map support provides intelligent null handling and type conversion for Java Collections. -~~~~~~~ -{snippet:id=javadoc|javadoc=true|url=com.opensymphony.xwork2.conversion.impl.DefaultObjectTypeDeterminer} -~~~~~~~ +The framework supports ways to discover the object type for elements in a collection. The discover is made via an +`ObjectTypeDeterminer`. A default implementation is provided with the framework. The Javadocs explain how `Map` +and `Collection` support is discovered in the `DefaultObjectTypeDeterminer`. -Additionally, you can create your own custom +The `ObjectTypeDeterminer` looks at the `Class-conversion.properties` for entries that indicated what objects are +contained within Maps and Collections. For Collections, such as Lists, the element is specified using the pattern +`Element_xxx`, where `xxx` is the field name of the collection property in your action or object. For Maps, both the key +and the value may be specified by using the pattern `Key_xxx` and `Element_xxx`, respectively. -~~~~~~~ -ObjectTypeDeterminer -~~~~~~~ - by implementing the +From WebWork 2.1.x, the `Collection_xxx` format is still supported and honored, although it is deprecated and will be +removed eventually. -~~~~~~~ -ObjectTypeDeterminer -~~~~~~~ - interface\. There is also an optional ObjectTypeDeterminer that utilizes Java 5 generics\. See the [Annotations](#PAGE_14017) page for more information\. +Additionally, you can create your own custom `ObjectTypeDeterminer` by implementing the `ObjectTypeDeterminer` interface. +There is also an optional `ObjectTypeDeterminer` that utilizes Java 5 generics. See the [Annotations](annotations.html) +page for more information. -__Indexing a collection by a property of that collection__ +### Indexing a collection by a property of that collection -It is also possible to obtain a unique element of a collection by passing the value of a given property of that element\. By default, the property of the element of the collection is determined in _Class_ \-conversion\.properties using - -~~~~~~~ -KeyProperty_xxx=yyy -~~~~~~~ -, where xxx is the property of the bean _Class_ that returns the collection and yyy is the property of the collection element that we want to index on\. +It is also possible to obtain a unique element of a collection by passing the value of a given property of that element. +By default, the property of the element of the collection is determined in `<Class>-conversion.properties` using +`KeyProperty_xxx=yyy`, where xxx is the property of the bean `Class` that returns the collection and yyy is the property +of the collection element that we want to index on. For an example, see the following two classes: -**MyAction\.java** - - -~~~~~~~ +**MyAction.java** +```java /** * @return a Collection of Foo objects */ @@ -209,14 +236,11 @@ public Collection getFooCollection() { return foo; } +``` -~~~~~~~ - -**Foo\.java** - - -~~~~~~~ +**Foo.java** +```java /** * @return a unique identifier */ @@ -224,146 +248,34 @@ public Long getId() { return id; } +``` -~~~~~~~ - -To enable type conversion, put the instruction - -~~~~~~~ -KeyProperty_fooCollection=id -~~~~~~~ - in the - -~~~~~~~ -MyAction-conversion.properties -~~~~~~~ - file\. This technique allows use of the idiom - -~~~~~~~ -fooCollection(someIdValue) -~~~~~~~ - to obtain the Foo object with value - -~~~~~~~ -someIdValue -~~~~~~~ - in the Set - -~~~~~~~ -fooCollection -~~~~~~~ -\. For example, - -~~~~~~~ -fooCollection(22) -~~~~~~~ - would return the Foo object in the - -~~~~~~~ -fooCollection -~~~~~~~ - Collection whose - -~~~~~~~ -id -~~~~~~~ - property value was 22\. - -This technique is useful, because it ties a collection element directly to its unique identifier\. You are not forced to use an index\. You can edit the elements of a collection associated to a bean without any additional coding\. For example, parameter name +To enable type conversion, put the instruction `KeyProperty_fooCollection=id` in the `MyAction-conversion.properties` +file. This technique allows use of the idiom `fooCollection(someIdValue)` to obtain the Foo object with value +`someIdValue` in the Set `fooCollection`. For example, `fooCollection(22)` would return the Foo object +in the `fooCollection` Collection whose `id` property value was 22. -~~~~~~~ -fooCollection(22).name -~~~~~~~ - and value +This technique is useful, because it ties a collection element directly to its unique identifier. You are not forced +to use an index. You can edit the elements of a collection associated to a bean without any additional coding. +For example, parameter name `fooCollection(22).name` and value `Phil` would set name the Foo Object in +the `fooCollection` Collection whose `id` property value was 22 to be Phil. -~~~~~~~ -Phil -~~~~~~~ - would set name the Foo Object in the +The framework automatically converts the type of the parameter sent in to the type of the key property using type conversion. -~~~~~~~ -fooCollection -~~~~~~~ - Collection whose +Unlike Map and List element properties, if `fooCollection(22)` does not exist, it will not be created. If you would +like it created, use the notation `fooCollection.makeNew[index]` where `index` is an integer 0, 1, and so on. Thus, +parameter value pairs `fooCollection.makeNew[0]=Phil` and `fooCollection.makeNew[1]=John` would add two new Foo Objects +to `fooCollection` - one with name property value `Phil` and the other with name property value `John`. However, +in the case of a Set, the `equals` and `hashCode` methods should be defined such that they don't only include the `id` +property. Otherwise, one element of the null `id` properties Foos to be removed from the Set. -~~~~~~~ -id -~~~~~~~ - property value was 22 to be Phil\. +### An advanced example for indexed Lists and Maps -The framework automatically converts the type of the parameter sent in to the type of the key property using type conversion\. +Here is the model bean used within the list. The KeyProperty for this bean is the `id` attribute. -Unlike Map and List element properties, if - -~~~~~~~ -fooCollection(22) -~~~~~~~ - does not exist, it will not be created\. If you would like it created, use the notation - -~~~~~~~ -fooCollection.makeNew[index] -~~~~~~~ - where _index_ is an integer 0, 1, and so on\. Thus, parameter value pairs - -~~~~~~~ -fooCollection.makeNew[0]=Phil -~~~~~~~ - and - -~~~~~~~ -fooCollection.makeNew[1]=John -~~~~~~~ - would add two new Foo Objects to - -~~~~~~~ -fooCollection -- -~~~~~~~ - one with name property value - -~~~~~~~ -Phil -~~~~~~~ - and the other with name property value - -~~~~~~~ -John -~~~~~~~ -\. However, in the case of a Set, the - -~~~~~~~ -equals -~~~~~~~ - and - -~~~~~~~ -hashCode -~~~~~~~ - methods should be defined such that they don't only include the - -~~~~~~~ -id -~~~~~~~ - property\. Otherwise, one element of the null - -~~~~~~~ -id -~~~~~~~ - properties Foos to be removed from the Set\. - -####An advanced example for indexed Lists and Maps#### - -Here is the model bean used within the list\. The KeyProperty for this bean is the - -~~~~~~~ -id -~~~~~~~ - attribute\. - -**MyBean\.java** - - -~~~~~~~ +**MyBean.java** +```java public class MyBean implements Serializable { private Long id; @@ -393,21 +305,13 @@ public class MyBean implements Serializable { '}'; } } +``` -~~~~~~~ - -The Action has a +The Action has a `beanList` attribute initialized with an empty `ArrayList`. -~~~~~~~ -beanList -~~~~~~~ - attribute initialized with an empty ArrayList\. - -**MyBeanAction\.java** - - -~~~~~~~ +**MyBeanAction.java** +```java public class MyBeanAction implements Action { private List beanList = new ArrayList(); @@ -433,92 +337,84 @@ public class MyBeanAction implements Action { return SUCCESS; } } +``` -~~~~~~~ - -These +These `conversion.properties` tell the TypeConverter to use MyBean instances as elements of the List. -~~~~~~~ -conversion.properties -~~~~~~~ - tell the TypeConverter to use MyBean instances as elements of the List\. - -**MyBeanAction\-conversion\.properties** - - -~~~~~~~ +**MyBeanAction-conversion.properties** +``` KeyProperty_beanList=id Element_beanList=MyBean CreateIfNull_beanList=true +``` -~~~~~~~ - -+ When submitting this via a form, the - -~~~~~~~ -id -~~~~~~~ - value is used as KeyProperty for the MyBean instances in the beanList\. - -+ Notice the () notation\! Do not use \[\] notation, which is for Maps only\! - -+ The value for name will be set to the MyBean instance with this special id\. - -+ The List does not have null values added for unavailable id values\. This approach avoids the risk of OutOfMemoryErrors\! - -**MyBeanAction\.jsp** +- When submitting this via a form, the `id` value is used as KeyProperty for the MyBean instances in the beanList. +- Notice the `()` notation! Do not use `[]` notation, which is for Maps only! +- The value for name will be set to the MyBean instance with this special id. +0 The List does not have null values added for unavailable id values. This approach avoids the risk of `OutOfMemoryErrors`! +**MyBeanAction.jsp** -~~~~~~~ - +```jsp <s:iterator value="beanList" id="bean"> <stextfield name="beanList(%{bean.id}).name" /> </s:iterator> +``` + +## Type Conversion Error Handling -~~~~~~~ +Type conversion error handling provides a simple way to distinguish between an input `validation` problem +and an input `type conversion` problem. -####Type Conversion Error Handling#### +Any error that occurs during type conversion may or may not wish to be reported. For example, reporting that the input +"abc" could not be converted to a number might be important. On the other hand, reporting that an empty string """, +cannot be converted to a number might not be important - especially in a web environment where it is hard to distinguish +between a user not entering a value vs. entering a blank value. -Type conversion error handling provides a simple way to distinguish between an input _validation_ problem and an input _type conversion_ problem\. +By default, all conversion errors are reported using the generic i18n key `xwork.default.invalid.fieldvalue`, +which you can override (the default text is _Invalid field value for field "xxx"_, where xxx is the field name) +in your global i18n resource bundle. +However, sometimes you may wish to override this message on a per-field basis. You can do this by adding an i18n +key associated with just your action (`Action.properties`) using the pattern `invalid.fieldvalue.xxx`, where xxx +is the field name. -~~~~~~~ -{snippet:id=error-reporting|javadoc=true|url=com.opensymphony.xwork2.conversion.impl.XWorkConverter} -~~~~~~~ +It is important to know that none of these errors are actually reported directly. Rather, they are added to a map +called _conversionErrors_ in the ActionContext. There are several ways this map can then be accessed and the errors +can be reported accordingly. There are two ways the error reporting can occur: 1. Globally, using the [Conversion Error Interceptor](conversion-error-interceptor.html) - 2. On a per-field basis, using the [conversion validator](conversion-validator.html) -By default, the conversion interceptor is included in - -~~~~~~~ +By default, the conversion interceptor is included in [struts-default.xml](struts-default-xml.html) in the default stack. +To keep conversion errors from reporting globally, change the interceptor stack, and add additional validation rules. -~~~~~~~ - in the default stack\. To keep conversion errors from reporting globally, change the interceptor stack, and add additional validation rules\. +## Common Problems -####Common Problems#### +### Null and Blank Values -#####Null and Blank Values##### +Some properties cannot be set to null. Primitives like boolean and int cannot be null. If your action needs to or will +accept null or blank values, use the object equivalents Boolean and Integer. Similarly, a blank string "" cannot be set +on a primitive. At the time of writing, a blank string also cannot be set on a BigDecimal or BigInteger. Use server-side +validation to prevent invalid values from being set on your properties (or handle the conversion errors appropriately). -Some properties cannot be set to null\. Primitives like boolean and int cannot be null\. If your action needs to or will accept null or blank values, use the object equivalents Boolean and Integer\. Similarly, a blank string "" cannot be set on a primitive\. At the time of writing, a blank string also cannot be set on a BigDecimal or BigInteger\. Use server\-side validation to prevent invalid values from being set on your properties (or handle the conversion errors appropriately)\. +### Interfaces -#####Interfaces##### +The framework cannot instantiate an object if it can't determine an appropriate implementation. It recognizes well-known +collection interfaces (List, Set, Map, etc) but cannot instantiate MyCustomInterface when all it sees is the interface. +In this case, instantiate the target implementation first (eg. in a prepare method) or substitute in an implementation. -The framework cannot instantiate an object if it can't determine an appropriate implementation\. It recognizes well\-known collection interfaces (List, Set, Map, etc) but cannot instantiate MyCustomInterface when all it sees is the interface\. In this case, instantiate the target implementation first (eg\. in a prepare method) or substitute in an implementation\. +### Generics and Erasure -#####Generics and Erasure##### - -The framework will inspect generics to determine the appropriate type for collections and array elements\. However, in some cases Erasure can result in base types that cannot be converted (typically Object or Enum)\. +The framework will inspect generics to determine the appropriate type for collections and array elements. However, in +some cases Erasure can result in base types that cannot be converted (typically Object or Enum). The following is an example of this problem: - -~~~~~~~ - +```java public abstract class Measurement<T extends Enum> public void setUnits(T enumValue) {...} } @@ -527,7 +423,9 @@ public class Area extends Measurement<UnitsOfArea> { @Override public void setUnits(UnitsOfArea enumValue){...} } +``` -~~~~~~~ - -Although to the developer the area\.setUnits(enumValue) method only accepts a UnitsOfArea enumeration, due to erasure the signature of this method is actually setUnits(java\.lang\.Enum)\. The framework does not know that the parameter is a UnitsOfArea and when it attempts to instantiate the Enum an exception is thrown (java\.lang\.IllegalArgumentException: java\.lang\.Enum is not an enum type)\. +Although to the developer the area.setUnits(enumValue) method only accepts a UnitsOfArea enumeration, due to erasure +the signature of this method is actually setUnits(java.lang.Enum). The framework does not know that the parameter is +a UnitsOfArea and when it attempts to instantiate the Enum an exception is thrown (java.lang.IllegalArgumentException: +java.lang.Enum is not an enum type). http://git-wip-us.apache.org/repos/asf/struts-site/blob/b4f6a844/source/core-developers/validation.md ---------------------------------------------------------------------- diff --git a/source/core-developers/validation.md b/source/core-developers/validation.md index 29f84de..37d1cc2 100644 --- a/source/core-developers/validation.md +++ b/source/core-developers/validation.md @@ -5,144 +5,91 @@ title: Validation # Validation -Struts 2 validation is configured via XML or annotations\. Manual validation in the action is also possible, and may be combined with XML and annotation\-driven validation\. +Struts 2 validation is configured via XML or annotations. Manual validation in the action is also possible, and may be +combined with XML and annotation-driven validation. -Validation also depends on both the +Validation also depends on both the `validation` and `workflow` interceptors (both are included in the default interceptor +stack). The `validation` interceptor does the validation itself and creates a list of field-specific errors. +The `workflow` interceptor checks for the presence of validation errors: if any are found, it returns the "input" result +(by default), taking the user back to the form which contained the validation errors. -~~~~~~~ -validation -~~~~~~~ - and +If we're using the default settings _and_ our action does not have an "input" result defined _and_ there are validation +(or, incidentally, type conversion) errors, we'll get an error message back telling us there's no "input" result defined +for the action. -~~~~~~~ -workflow -~~~~~~~ - interceptors (both are included in the default interceptor stack)\. The - -~~~~~~~ -validation -~~~~~~~ - interceptor does the validation itself and creates a list of field\-specific errors\. The - -~~~~~~~ -workflow -~~~~~~~ - interceptor checks for the presence of validation errors: if any are found, it returns the "input" result (by default), taking the user back to the form which contained the validation errors\. - -If we're using the default settings _and_ our action doesn't have an "input" result defined _and_ there are validation (or, incidentally, type conversion) errors, we'll get an error message back telling us there's no "input" result defined for the action\. - -**CONTENTS** - - -####Using Annotations#### - -[Annotations](validation-annotation.html) can be used as an alternative to XML for validation\. +## Using Annotations +[Annotations](validation-annotation.html) can be used as an alternative to XML for validation. Â +## Bean Validation -####Bean Validation#### - -With struts 2\.5 comes the Bean Validation Plugin\. That is an alternative to the classic struts validation described here\. See the _Plugin Page_ for details\. +With struts 2.5 comes the Bean Validation Plugin. That is an alternative to the classic struts validation described here. +See the [Plugin Page](../plugins/) for details. -####Examples#### +## Examples -In all examples given here, the validation message displayed is given in plain English \- to internationalize the message, put the string in a properties file and use a property key instead, specified by the 'key' attribute\. It will be looked up by the framework (see [Localization](localization.html)). +In all examples given here, the validation message displayed is given in plain English - to internationalize the message, +put the string in a properties file and use a property key instead, specified by the 'key' attribute. It will be looked +up by the framework (see [Localization](localization.html)). 1. [Basic Validation](basic-validation.html) - 2. [Client-side Validation](client-side-validation.html) - 3. _AJAX Validation_ - 4. [Using Field Validators](using-field-validators.html) - 5. [Using Non Field Validators](using-non-field-validators.html) - 6. [Using Visitor Field Validator](using-visitor-field-validator.html) - 7. _How do we repopulate controls when validation fails_ (FAQ entry) -####Bundled Validators#### - +## Bundled Validators -When using a Field Validator, Field Validator Syntax is **ALWAYS** preferable than using the Plain Validator Syntax as it facilitates grouping of field\-validators according to fields\. This is very handy especially if a field needs to have many field\-validators which is almost always the case\. - -| +When using a Field Validator, Field Validator Syntax is **ALWAYS** preferable than using the Plain Validator Syntax +as it facilitates grouping of field-validators according to fields. This is very handy especially if a field needs +to have many field-validators which is almost always the case. 1. [conversion validator](conversion-validator.html) - 2. [date validator](date-validator.html) - 3. [double validator](double-validator.html) - 4. [email validator](email-validator.html) - 5. [expression validator](expression-validator.html) - 6. [fieldexpression validator](fieldexpression-validator.html) - 7. [int validator](int-validator.html) - 8. [regex validator](regex-validator.html) - 9. [required validator](required-validator.html) - 10. [requiredstring validator](requiredstring-validator.html) - 11. [short validator](short-validator.html) - 12. [stringlength validator](stringlength-validator.html) - 13. [url validator](url-validator.html) - 14. [visitor validator](visitor-validator.html) - 15. [conditionalvisitor validator](conditionalvisitor-validator.html) -####Registering Validators#### +## Registering Validators +Validation rules are handled by validators, which must be registered with the ValidatorFactory (using the +`registerValidator` method). The simplest way to do so is to add a file name `validators.xml` in the root of the classpath +(/WEB-INF/classes) that declares all the validators you intend to use. +The following list shows the default validators included in the framework and is an example of the syntax used to declare +our own validators. -~~~~~~~ -{snippet:id=javadoc|javadoc=true|url=com.opensymphony.xwork2.validator/ValidatorFactory.java} -~~~~~~~ -The following list shows the default validators included in the framework and is an example of the syntax used to declare our own validators\. +{% highlight xml %} +{% remote_file_content https://raw.githubusercontent.com/apache/struts/master/core/src/main/resources/com/opensymphony/xwork2/validator/validators/default.xml %} +{% endhighlight %} -~~~~~~~ -{snippet:lang=xml|url=struts2/core/src/main/resources/com/opensymphony/xwork2/validator/validators/default.xml} -~~~~~~~ +> **Struts 2.1 and Prior** +> The `validators.xml` used to reference a DTD hosted by Opensymphony, the original location of the XWork project. +> Since they moved to Apache Struts, DTDs were changed. Please ensure in your projects to include the DTD header +> as described in the examples found here. +> **Struts 2.0.7 and Prior** +> The `validators.xml` containing custom validators needs to contain a copy of the default validators. No DTD was used +> in `validators.xml`. See: [http://struts.apache.org/docs/release-notes-208.html#ReleaseNotes2.0.8-MigrationfrompreviousReleases](http://struts.apache.org/docs/release-notes-208.html#ReleaseNotes2.0.8-MigrationfrompreviousReleases) -The validators\.xml used to reference a DTD hosted by Opensymphony, the original location of the XWork project\. Since the the move to Apache Struts, DTDs were changed\. Please ensure in your projects to include the DTD header as described in the examples found here +## Turning on Validation -| +The default interceptor stack, "defaultStack", already has validation turned on. When creating your own interceptor-stack +be sure to include **both** the `validation` and `workflow` interceptors. From `struts-default.xml`: - -The validators\.xml containing custom validators needs to contain a copy of the default validators\. No DTD was used in validators\.xml\. See: [http://struts\.apache\.org/2\.x/docs/release\-notes\-208\.html\#ReleaseNotes2\.0\.8\-MigrationfrompreviousReleases](http://struts\.apache\.org/2\.x/docs/release\-notes\-208\.html\#ReleaseNotes2\.0\.8\-MigrationfrompreviousReleases) - -| - -####Turning on Validation#### - -The default interceptor stack, "defaultStack", already has validation turned on\. When creating your own interceptor\-stack be sure to include **both** the - -~~~~~~~ -validation -~~~~~~~ - and - -~~~~~~~ -workflow -~~~~~~~ - interceptors\. From - -~~~~~~~ -struts-default.xml -~~~~~~~ -: - - -~~~~~~~ +```xml <interceptor-stack name="defaultStack"> ... <interceptor-ref name="validation"> @@ -152,151 +99,201 @@ struts-default.xml <param name="excludeMethods">input,back,cancel,browse</param> </interceptor-ref> </interceptor-stack> +``` -~~~~~~~ - -Beginning with version 2\.0\.4 Struts provides an extension to XWork's - -~~~~~~~ -com.opensymphony.xwork2.validator.ValidationInterceptor -~~~~~~~ - interceptor\. - +Beginning with version 2.0.4 Struts provides an extension to XWork's `com.opensymphony.xwork2.validator.ValidationInterceptor` +interceptor. -~~~~~~~ +```xml <interceptor name="validation" class="org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor"/> - -~~~~~~~ - -This interceptor allows us to turn off validation for a specific method by using the - -~~~~~~~ -@org.apache.struts2.interceptor.validation.SkipValidation -~~~~~~~ - annotation on the action method\. - -####Validator Scopes#### - - - -~~~~~~~ -{snippet:id=fieldValidators|javadoc=true|url=com.opensymphony.xwork2.validator/ValidatorFactory.java} -~~~~~~~ - - -~~~~~~~ -{snippet:id=nonFieldValidators|javadoc=true|url=com.opensymphony.xwork2.validator/ValidatorFactory.java} -~~~~~~~ - -#####Notes##### - - - -~~~~~~~ -{snippet:id=validatorsNote|javadoc=true|url=com.opensymphony.xwork2.validator/ValidatorFactory.java} -~~~~~~~ - -####Defining Validation Rules#### - - - -~~~~~~~ -{snippet:id=validationRules1|javadoc=true|url=com.opensymphony.xwork2.validator/ValidatorFactory.java} -~~~~~~~ - - -~~~~~~~ -{snippet:id=exValidationRules1|lang=xml|javadoc=true|url=com.opensymphony.xwork2.validator/ValidatorFactory.java} -~~~~~~~ - - -~~~~~~~ -{snippet:id=validationRules2|javadoc=true|url=com.opensymphony.xwork2.validator/ValidatorFactory.java} -~~~~~~~ - - -In this context, "Action Alias" refers to the action name as given in the Struts configuration\. Often, the name attribute matches the method name, but they may also differ\. - -| - -####Localizing and Parameterizing Messages#### - - - -~~~~~~~ -{snippet:id=validationRules3|javadoc=true|url=com.opensymphony.xwork2.validator/ValidatorFactory.java} -~~~~~~~ - - -~~~~~~~ -{snippet:id=exValidationRules3|javadoc=true|lang=xml|url=com.opensymphony.xwork2.validator/ValidatorFactory.java} -~~~~~~~ - - -~~~~~~~ -{snippet:id=validationRules4|javadoc=true|url=com.opensymphony.xwork2.validator/ValidatorFactory.java} -~~~~~~~ - - -~~~~~~~ -{snippet:id=exValidationRules4|javadoc=true|lang=xml|url=com.opensymphony.xwork2.validator/ValidatorFactory.java} -~~~~~~~ - -####Validator Flavor#### - - - -~~~~~~~ -{snippet:id=validatorFlavours|javadoc=true|url=com.opensymphony.xwork2.validator/Validator.java} -~~~~~~~ - -####Non\-Field Validator Vs Field\-Validator validatortypes#### - -There are two ways you can define validators in your \-validation\.xml file: - -1. <validator> - -2. <field-validator> +``` + +This interceptor allows us to turn off validation for a specific method by using the `@org.apache.struts2.interceptor.validation.SkipValidation` +annotation on the action method. + +## Validator Scopes + +Field validators, as the name indicate, act on single fields accessible through an action. A validator, in contrast, +is more generic and can do validations in the full action context, involving more than one field (or even no field +at all) in validation rule. Most validations can be defined on per field basis. This should be preferred over non-field +validation wherever possible, as field validator messages are bound to the related field and will be presented next +to the corresponding input element in the respecting view. + +Non-field validators only add action level messages. Non-field validators are mostly domain specific and therefore +offer custom implementations. The most important standard non-field validator provided by XWork is `ExpressionValidator`. + +## Notes + +Non-field validators takes precedence over field validators regardless of the order they are defined in `*-validation.xml`. +If a non-field validator is `short-circuited`, it will causes its non-field validator to not being executed. +See validation framework documentation for more info. + +## Defining Validation Rules + +Validation rules can be specified: +1. Per Action class: in a file named `ActionName-validation.xml` +2. Per Action alias: in a file named `ActionName-alias-validation.xml` +3. Inheritance hierarchy and interfaces implemented by Action class: + XWork searches up the inheritance tree of the action to find default + validations for parent classes of the Action and interfaces implemented + +Here is an example for SimpleAction-validation.xml: + +```xml +<!DOCTYPE validators PUBLIC "-//Apache Struts//XWork Validator 1.0.3//EN" + "http://struts.apache.org/dtds/xwork-validator-1.0.3.dtd";> +<validators> + <field name="bar"> + <field-validator type="required"> + <message>You must enter a value for bar.</message> + </field-validator> + <field-validator type="int"> + <param name="min">6</param> + <param name="max">10</param> + <message>bar must be between ${min} and ${max}, current value is ${bar}.</message> + </field-validator> + </field> + <field name="bar2"> + <field-validator type="regex"> + <param name="expression">[0-9],[0-9]</param> + <message>The value of bar2 must be in the format "x, y", where x and y are between 0 and 9</message> + </field-validator> + </field> + <field name="date"> + <field-validator type="date"> + <param name="min">12/22/2002</param> + <param name="max">12/25/2002</param> + <message>The date must be between 12-22-2002 and 12-25-2002.</message> + </field-validator> + </field> + <field name="foo"> + <field-validator type="int"> + <param name="min">0</param> + <param name="max">100</param> + <message key="foo.range">Could not find foo.range!</message> + </field-validator> + </field> + <validator type="expression"> + <param name="expression">foo lt bar </param> + <message>Foo must be greater than Bar. Foo = ${foo}, Bar = ${bar}.</message> + </validator> +</validators> +``` + +Here we can see the configuration of validators for the `SimpleActio`n 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 `<param>` elements with name and value attributes to set arbitrary parameters into the Validator instance. +See below for discussion of the message element. + +In this context, "Action Alias" refers to the action name as given in the Struts configuration. Often, the name attribute +matches the method name, but they may also differ. + +## Localizing and Parameterizing Messages + +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. 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). 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 `${...}` +sections which are replaced with the evaluated value of the string between the `${` and `}`. This allows you +to parameterize your messages with values from the Validator, the Action, or both. + +If the validator fails, the validator is pushed onto the ValueStack and the message - either the default or +the locale-specific one if the key attribute is defined (and such a message exists) - is parsed for `${...}` sections +which are replaced with the evaluated value of the string between the `${` and `}`. This allows you to parameterize +your messages with values from the validator, the Action, or both. + +> Since validation rules are in an XML file, you must make sure you escape special characters. For example, notice +> that in the expression validator rule above we use ">" instead of ">". Consult a resource on XML +> for the full list of characters that must be escaped. The most commonly used characters that must be escaped +> are: & (use &), < (use <), and > (use >). + +Here is an example of a parameterized message: + +This will pull the min and max parameters from the IntRangeFieldValidator and the value of bar from the Action. + +``` +bar must be between ${min} and ${max}, current value is ${bar}. +``` + +Another notable fact is that the provided message value is capable of containing OGNL expressions. Keeping this in mind, +it is possible to construct quite sophisticated messages. + +See the following example to get an impression: + +```xml +<message>${getText("validation.failednotice")} ! ${getText("reason")}: ${getText("validation.inputrequired")}</message> +``` + +## Validator Flavor + +The validators supplied by the XWork distribution (and any validators you might write yourself) come in two different +flavors: + +1. Plain Validators / Non-Field validators +2. FieldValidators + +Plain Validators (such as the `ExpressionValidator`) perform validation checks that are not inherently tied to a single +specified field. When you declare a plain Validator in your `-validation.xml` file you do not associate a `fieldname` +attribute with it. You should avoid using plain Validators within the `<field-validator>` syntax described below. + +FieldValidators (such as the `EmailValidator`) are designed to perform validation checks on a single field. They require +that you specify a `fieldname` attribute in your `-validation.xml` file. There are two different (but equivalent) +XML syntaxes you can use to declare FieldValidators (see "<validator> vs. <field-Validator> syntax" below). + +There are two places where the differences between the two validator flavors are important to keep in mind: + +1. when choosing the xml syntax used for declaring a validator (either `<validator>` or `<field-validator>`) +2. when using the `short-circuit` capability + +> Note that you do not declare what "flavor" of validator you are using in your `-validation.xml` file, you just declare +> the name of the validator to use and Struts will know whether it's a "plain Validator" or a "FieldValidator" +> by looking at the validation class that the validator's programmer chose to implement. + +## Non-Field Validator Vs Field-Validator validatortypes + +There are two ways you can define validators in your `-validation.xml` file: + +1. `<validator>` +2. `<field-validator>` Keep the following in mind when using either syntax: -Non\-Field\-Validator: The \<validator\> element allows you to declare both types of validators (either a plain Validator a field\-specific FieldValidator)\. - +Non-Field-Validator: The `<validator>` element allows you to declare both types of validators (either a plain Validator +a field-specific FieldValidator). -~~~~~~~ +```xml <validator type="expression> <param name="expression">foo gt bar</param> <message>foo must be great than bar.</message> </validator> +``` -~~~~~~~ - - -~~~~~~~ +```xml <validator type="required"> <param name="fieldName">bar</param> <message>You must enter a value for bar.</message> </validator> +``` -~~~~~~~ - -**field\-validator**: The \<field\-validator\> elements are basically the same as the \<validator\> elements except that they inherit the fieldName attribute from the enclosing \<field\> element\. FieldValidators defined within a \<field\-validator\> element will have their fieldName automatically filled with the value of the parent \<field\> element's fieldName attribute\. The reason for this structure is to conveniently group the validators for a particular field under one element, otherwise the fieldName attribute would have to be repeated, over and over, for each individual \<validator\>\. - - +**field-validator**: The `<field-validator>` elements are basically the same as the `<validator>` elements except that +they inherit the `fieldName` attribute from the enclosing `<field>` element. FieldValidators defined within a `<field-validator`> +element will have their `fieldName` automatically filled with the value of the parent `<field>` element's `fieldName` + attribute. The reason for this structure is to conveniently group the validators for a particular field under one element, + otherwise the fieldName attribute would have to be repeated, over and over, for each individual `<validator>`. -| It is always better to defined field\-validator inside a \<field\> tag instead of using a \<validator\> tag and supplying fieldName as its param as the xml code itself is clearer (grouping of field is clearer) +It is always better to defined field-validator inside a `<field>` tag instead of using a `<validator>` tag and supplying +`fieldName` as its param as the xml code itself is clearer (grouping of field is clearer). -| +> Note that you should only use FieldValidators (not plain Validators) within a block. A plain Validator inside +> a `<field>` will not be allowed and would generate error when parsing the xml, as it is not allowed +> in the defined DTD (xwork-validator-1.0.2.dtd) +Declaring a FieldValidator using the `<field-validator>` syntax: -Note that you should only use FieldValidators (not plain Validators) within a block\. A plain Validator inside a \<field\> will not be allowed and would generate error when parsing the xml, as it is not allowed in the defined dtd (xwork\-validator\-1\.0\.2\.dtd) - -| - -Declaring a FieldValidator using the \<field\-validator\> syntax: - - -~~~~~~~ +```xml <field name="email_address"> <field-validator type="required"> <message>You cannot leave the email address field empty.</message> @@ -305,13 +302,12 @@ Declaring a FieldValidator using the \<field\-validator\> syntax: <message>The email address you entered is not valid.</message> </field-validator> </field> +``` -~~~~~~~ +The choice is yours. It's perfectly legal to only use elements without the elements and set the `fieldName` attribute +for each of them. The following are effectively equal: -The choice is yours\. It's perfectly legal to only use elements without the elements and set the fieldName attribute for each of them\. The following are effectively equal: - - -~~~~~~~ +```xml <field name="email_address"> <field-validator type="required"> <message>You cannot leave the email address field empty.</message> @@ -329,62 +325,126 @@ The choice is yours\. It's perfectly legal to only use elements without the elem <param name="fieldName">email_address</param> <message>The email address you entered is not valid.</message> </validator> - -~~~~~~~ - -####Short\-Circuiting Validator#### - - - -~~~~~~~ -{snippet:id=shortCircuitingValidators1|javadoc=true|url=com.opensymphony.xwork2.validator/Validator.java} -~~~~~~~ - - -~~~~~~~ -{snippet:id=exShortCircuitingValidators|lang=xml|javadoc=true|url=com.opensymphony.xwork2.validator/Validator.java} -~~~~~~~ - - -~~~~~~~ -{snippet:id=shortCircuitingValidators2|javadoc=true|url=com.opensymphony.xwork2.validator/Validator.java} -~~~~~~~ - - -~~~~~~~ -{snippet:id=scAndValidatorFlavours1|1=javadoc|javadoc=true|url=com.opensymphony.xwork2.validator/Validator.java} -~~~~~~~ - - -~~~~~~~ -{snippet:id=exScAndValidatorFlavours|lang=xml|javadoc=true|url=com.opensymphony.xwork2.validator/Validator.java} -~~~~~~~ - - -~~~~~~~ -{snippet:id=scAndValidatorFlavours2|1=javadoc|javadoc=true|url=com.opensymphony.xwork2.validator/Validator.java} -~~~~~~~ - -####How Validators of an Action are Found#### - - - -~~~~~~~ -{snippet:id=howXworkFindsValidatorForAction|javadoc=true|url=com.opensymphony.xwork2.validator/Validator.java} -~~~~~~~ - -####Writing custom validators#### +``` + +## Short-Circuiting Validator + +It is possible to `short-circuit` a stack of validators. Here is another sample config file containing validation +rules from the Xwork test cases: Notice that some of the `<field-validator>` and `<validator>` elements have +the `short-circuit` attribute set to true. + +```xml +<!DOCTYPE validators PUBLIC + "-//Apache Struts//XWork Validator 1.0.3//EN" + "http://struts.apache.org/dtds/xwork-validator-1.0.3.dtd";> +<validators> + <!-- Field Validators for email field --> + <field name="email"> + <field-validator type="required" short-circuit="true"> + <message>You must enter a value for email.</message> + </field-validator> + <field-validator type="email" short-circuit="true"> + <message>Not a valid e-mail.</message> + </field-validator> + </field> + <!-- Field Validators for email2 field --> + <field name="email2"> + <field-validator type="required"> + <message>You must enter a value for email2.</message> + </field-validator> + <field-validator type="email"> + <message>Not a valid e-mail2.</message> + </field-validator> + </field> + <!-- Plain Validator 1 --> + <validator type="expression"> + <param name="expression">email.equals(email2)</param> + <message>Email not the same as email2</message> + </validator> + <!-- Plain Validator 2 --> + <validator type="expression" short-circuit="true"> + <param name="expression">email.startsWith('mark')</param> + <message>Email does not start with mark</message> + </validator> +</validators> +``` + +**short-circuiting and Validator flavors** + +Plain validator takes precedence over field-validator. They get validated first in the order they are defined and then +the field-validator in the order they are defined. Failure of a particular validator marked as short-circuit will +prevent the evaluation of subsequent validators and an error (action error or field error depending on the type of validator) +will be added to the `ValidationContext` of the object being validated. + +In the example above, the actual execution of validator would be as follows: + +1. Plain Validator 1 +2. Plain Validator 2 +3. Field Validators for email field +4. Field Validators for email2 field + +Since Plain Validator 2 is short-circuited, if its validation failed, it will causes Field validators for email field +and Field validators for email2 field to not be validated as well. + +**Usefull Information:** +More complicated validation should probably be done in the `validate()` method on the action itself (assuming the action +implements `Validatable` interface which `ActionSupport` already does). + +A plain Validator (non FieldValidator) that gets short-circuited will completely break out of the validation stack. +No other validators will be evaluated and plain validators takes precedence over field validators meaning that they +get evaluated in the order they are defined before field validators get a chance to be evaluated. + +**Short cuircuiting and validator flavours** + +A FieldValidator that gets short-circuited will only prevent other FieldValidators for the same field from being +evaluated. Note that this "same field" behavior applies regardless of whether the `<validator>` or `<field-validator>` +syntax was used to declare the validation rule. By way of example, given this `-validation.xml` file: + +```xml +<validator type="required" short-circuit="true"> + <param name="fieldName">bar</param> + <message>You must enter a value for bar.</message> +</validator> + +<validator type="expression"> + <param name="expression">foo gt bar</param> + <message>foo must be great than bar.</message> +</validator> +``` + +both validators will be run, even if the "required" validator short-circuits. "required" validators are FieldValidator's +and will not short-circuit the plain ExpressionValidator because FieldValidators only short-circuit other checks on that +same field. Since the plain Validator is not field specific, it is not short-circuited. + +## How Validators of an Action are Found + +As mentioned above, the framework will also search up the inheritance tree of the action to find default validations +for interfaces and parent classes of the Action. If you are using the short-circuit attribute and relying on default +validators higher up in the inheritance tree, make sure you don't accidentally short-circuit things higher in the tree +that you really want! + +The effect of having common validators on both + +- `<actionClass>-validation.xml` +- `<actionClass>-<actionAlias>-validation.xml` + +It should be noted that the nett effect will be validation on both the validators available in both validation +configuration file. For example if we have 'requiredstring' validators defined in both validation xml file for field +named 'address', we will see 2 validation error indicating that the the address cannot be empty (assuming validation +failed). This is due to WebWork will merge validators found in both validation configuration files. + +The logic behind this design decision is such that we could have common validators in `<actionClass>-validation.xml` +and more context specific validators to be located in `<actionClass>-<actionAlias>-validation.xml`. + +## Writing custom validators If you want to write custom validator use on of these classes as a starting point: -+ com\.opensymphony\.xwork2\.validator\.validators\.ValidatorSupport - -+ com\.opensymphony\.xwork2\.validator\.validators\.FieldValidatorSupport - -+ com\.opensymphony\.xwork2\.validator\.validators\.RangeValidatorSupport - -+ com\.opensymphony\.xwork2\.validator\.validators\.RepopulateConversionErrorFieldValidatorSupport +- `com.opensymphony.xwork2.validator.validators.ValidatorSupport` +- `com.opensymphony.xwork2.validator.validators.FieldValidatorSupport` +- `com.opensymphony.xwork2.validator.validators.RangeValidatorSupport` +- `com.opensymphony.xwork2.validator.validators.RepopulateConversionErrorFieldValidatorSupport` -####Resources#### +## Resources -[WebWork Validation](http://today\.java\.net/pub/a/today/2006/01/19/webwork\-validation\.html)^[http://today\.java\.net/pub/a/today/2006/01/19/webwork\-validation\.html] +[WebWork Validation](http://today.java.net/pub/a/today/2006/01/19/webwork-validation.html) http://git-wip-us.apache.org/repos/asf/struts-site/blob/b4f6a844/source/core-developers/writing-interceptors.md ---------------------------------------------------------------------- diff --git a/source/core-developers/writing-interceptors.md b/source/core-developers/writing-interceptors.md index 09154bf..e96843e 100644 --- a/source/core-developers/writing-interceptors.md +++ b/source/core-developers/writing-interceptors.md @@ -5,17 +5,15 @@ title: Writing Interceptors # Writing Interceptors -See the [Interceptors](interceptors.html) page for an overview of how interceptors work\. +See the [Interceptors](interceptors.html) page for an overview of how interceptors work. -__Interceptor interface__ +## Interceptor interface -Interceptors must implement the com\.opensymphony\.xwork2\.interceptor\.Interceptor interface\. +Interceptors must implement the `com.opensymphony.xwork2.interceptor.Interceptor` interface. -**Interceptor\.java** - - -~~~~~~~ +**Interceptor.java** +```java public interface Interceptor extends Serializable { void destroy(); @@ -24,44 +22,40 @@ public interface Interceptor extends Serializable { String intercept(ActionInvocation invocation) throws Exception; } +``` -~~~~~~~ - -The _init_ method is called the after interceptor is instantiated and before calling _intercept_ \. This is the place to allocate any resources used by the interceptor\. - -The _intercept_ method is where the interceptor code is written\. Just like an action method, _intercept_ returns a result used by Struts to forward the request to another web resource\. Calling _invoke_ on the parameter of type ActionInvocation will execute the action (if this is the last interceptor on the stack) or another interceptor\. - - - -| Keep in mind that _invoke_ will return **after** the result has been called (eg\. after you JSP has been rendered), making it perfect for things like open\-session\-in\-view patterns\. If you want to do something before the result gets called, you should implement a PreResultListener\. +The `init` method is called the after interceptor is instantiated and before calling `intercept`. This is the place +to allocate any resources used by the interceptor. -| +The `intercept` method is where the interceptor code is written. Just like an action method, `intercept` returns +a result used by Struts to forward the request to another web resource. Calling `invoke` on the parameter of type +`ActionInvocation` will execute the action (if this is the last interceptor on the stack) or another interceptor. -Overwrite _destroy_ to release resources on application shutdown\. +> Keep in mind that `invoke` will return **after** the result has been called (eg. after you JSP has been rendered), +> making it perfect for things like open-session-in-view patterns. If you want to do something before the result gets +> called, you should implement a `PreResultListener`. -__Thread Safety__ +Overwrite `destroy` to release resources on application shutdown. -**Interceptors must be thread\-safe\!** +## Thread Safety -> +**Interceptors must be thread-safe!** -> +> A Struts 2 Action instance is created for every request and do not need to be thread-safe. Conversely, Interceptors +> are shared between requests and must be [thread-safe](http://en.wikipedia.org/wiki/Thread-safety). -> A Struts 2 Action instance is created for every request and do not need to be thread\-safe\. Conversely, Interceptors are shared between requests and must be [thread\-safe](http://en\.wikipedia\.org/wiki/Thread\-safety)^[http://en\.wikipedia\.org/wiki/Thread\-safety]\. -> +## AbstractInterceptor -__AbstractInterceptor__ +The AbstractInterceptor class provides an empty implementation of `init` and `destroy`, and can be used if these +methods are not going to be implemented. -The AbstractInterceptor class provides an empty implementation of _init_ and _destroy_ , and can be used if these methods are not going to be implemented\. +## Mapping -__Mapping__ - -Interceptors are declared using the _interceptor_ element, nested inside the _interceptors_ element\. Example from struts\-default\.xml: - - -~~~~~~~ +Interceptors are declared using the `<interceptor/>` element, nested inside the `<interceptors/>` element. +Example from `struts-default.xml`: +```xml <struts> ... @@ -75,18 +69,16 @@ Interceptors are declared using the _interceptor_ element, nested inside the _i ... </struts> +``` -~~~~~~~ - -__Example__ +### Example -Assuming there is an action of type "MyAction", with a setDate(Date) method, this simple interceptor will set the date of the action to the current date: +Assuming there is an action of type "MyAction", with a setDate(Date) method, this simple interceptor will set the date +of the action to the current date: **Interceptor Example** - -~~~~~~~ - +```java import com.opensymphony.xwork2.ActionInvocation; import com.opensymphony.xwork2.interceptor.AbstractInterceptor; @@ -98,5 +90,4 @@ public class SimpleInterceptor extends AbstractInterceptor { return invocation.invoke(); } } - -~~~~~~~ +```
