RFC 1867

Dependencies

The Struts 2 framework leverages add-on libraries to handle the parsing of uploaded files. These libraries are not included in the Struts distribution, you must add them into your project. The libraries needed are:

Library	URL	Struts 2.0.x	Struts 2.1.x
Commons-FileUpload	http://commons.apache.org/fileupload/	1.1.1	1.2.1
Commons-IO	http://commons.apache.org/io/	1.0	1.3.2

References:

http://www.struts2.org/ajax-file-upload-in-struts2-using-ajax-file-upload-plugin/

http://www.javaeye.com/problems/1818

Many Actions share common concerns. Some Actions need input validated. Other Actions may need a file upload to be pre-processed. Another Action might need protection from a double submit. Many Actions need drop-down lists and other controls pre-populated before the page displays.

The framework makes it easy to share solutions to these concerns using an “Interceptor” strategy. When you request a resource that maps to an “action”, the framework invokes the Action object. But, before the Action is executed, the invocation can be intercepted by another object. After the Action executes, the invocation could be intercepted again. Unsurprisingly, we call these objects “Interceptors.”

Interceptors can execute code before and after an Action is invoked. Most of the framework’s core functionality is implemented as Interceptors. Features like double-submit guards, type conversion, object population, validation, file upload, page preparation, and more, are all implemented with the help of Interceptors. Each and every Interceptor is pluggable, so you can decide exactly which features an Action needs to support.

Interceptors can be configured on a per-action basis. Your own custom Interceptors can be mixed-and-matched with the Interceptors bundled with the framework. Interceptors “set the stage” for the Action classes, doing much of the “heavy lifting” before the Action executes.

In some cases, an Interceptor might keep an Action from firing, because of a double-submit or because validation failed. Interceptors can also change the state of an Action before it executes.

The Interceptors are defined in a stack that specifies the execution order. In some cases, the order of the Interceptors on the stack can be very important.

References:

http://docs.huihoo.com/apache/struts/apache-struts-2-document/interceptors.html

Struts2 supports localization (l10n) aware formatting of dates, times and numbers very easily, utilizing Java’s built-in date formatting features.

As seen in the Localization chapter, it is quite easy to define hierarchical resource bundles with Struts2, giving the developer the opportunity to define locale dependent message formats. This is the entry point to define the needed date, time and number formats. Your default properties could contain the following generic formats:

format.time = {0,time}
format.number = {0,number,#0.0##}
format.percent = {0,number,##0.00'%'}
format.money = {0,number,\u00A4##0.00}

An appropriate en_US format definition extension could look like this:

format.date = {0,date,MM/dd/yy}

In parallel, you could add the following to your de_DE bundle:

format.date = {0,date,dd.MM.yyyy}

Read more on how to define message formats in Sun’s Java API docs for MessageFormat.

Now that we have our formats set up, it is quite easy to use them in our views.

Formatting output using the s:text tag

Given you had a Float value myMoneyValue, accessible through the getter getMyMoneyValue in your action, the following code would print out localized representation of the value as a currency amount, using the format.money message format defined above with a s:text tag:

<s:text name="format.money">
    <s:param name="value" value="myMoneyValue"/>

References:

http://struts.apache.org/2.x/docs/formatting-dates-and-numbers.html

</s:text>

The (first) parameter defines the value which is to replace the ’0′ placeholder in the defined message format.
Another example, formatting a date value:

<s:text name="format.date"><s:param value="dueDate"/></s:text>

While the s:text tag is very useful to format numbers, date formatting has become a lot easier thanks to the s:date tag.

Localizing form data with getText

Placing a textfield in a form like this

<s:textfield key="orderItem.price" />

to input a number, one might have noticed that the number is always shown in the Java default number format. Not only that this is not “nice”, if you are in a non-en locale, it will also cause trouble when submitting the form since type conversion is locale aware. The solution is to again use the message formats as defined above, by using the getText Method of ActionSupport:

<s:textfield key="orderItem.price" value="%{getText('format.number',{'orderItem.price'})}" />

This maps to the method signature getText( String key, Object[] params ) in ActionSupport.