As already noted, there are Struts tags corresponding to most if not all of the traditional HTML form elements, as well as some other HTML fragments. Listed in the following table are some of the more commonly used HTML form tags and their common usage. For a complete list of the many tags provided by Struts, as well as the list of possible attributes, refer to the online documentation at http://struts.apache.org/userGuide/index.html.

It is important to note that many of the tags included in the Struts HTML tag library have many attributes to allow the developer full control over the functional and presentation capabilities of a JSP page employing these tags. For instance, many of the HTML tags allow the following attributes to be used:

All the items listed in this section must be used within the confines of an html:form element. Generally, with HTML form tags, a property attribute denotes the associated form bean property that this element represents.

html:form

The html:form tag, shown in the following code, defines a Struts-powered form in a JSP page and indicates to the framework that this entry and its corresponding closing tag contain form elements that will be populated by a Struts form bean object. Once processed, the tag will render a typical <form..> HTML tag to be used appropriately by the browser. The value of the action attribute must correspond to a defined action in struts.

<html:form action="/login" method="POST">
...
</html:form>

html:text

This tag renders an input type text form element.

<html:text property="firstName"/>

html:password

This tag renders an input type password form element. This tag is basically the same as the html:text tag except that the value is not readable to the user. This element can also be set to be blanked out if the form is redisplayed because of some validation error with the redisplay attribute.

<html:password property="password" redisplay="true"/>

html:textarea

This tag is used to render a text area HTML element based on the property specified.

<html:textarea property="comments"></html:textarea>

html:hidden

This tag renders a hidden HTML form element for the specified property.

<html:hidden property="id"/>

html:checkbox

This tag renders an HTML check box form element, with its state appropriate to the form bean property specified. The form bean should use a boolean type property to denote such values.

An interesting problem often associated with a check box is that were it to be deselected by the user and submitted, there would be no corresponding request attribute associated with this form element. Struts handles this problem by advising that the property should be set to false in the form bean's reset() method. This enables the property to reflect the desired value when the form is submitted.

<html:checkbox property="approved"/>

html:radio

This tag renders an HTML radio button element based on the property specified.

<html:radio property="sex" value="M"/>
<html:radio property="sex" value="F"/>

html:select and html:options

<html:select property="name">
    <html:options collection="myList" property="value" labelProperty="label"/>
</html:select>

This extremely convenient tag combination renders a select list of the objects stored in the Collection object nominated under the collection attribute. In the preceding example, the name myList refers to an ArrayList of LabelValueBean objects that has been added to the scope of the JSP page. The property attribute in the html:select tag refers to the property of the form bean this select list represents, while the property and labelProperty attributes of the html:options tag represent values of each object rendered within the select list. Therefore, you can surmise from this that each LabelValueBean has at least two getter methods, getValue() and getLabel(). Using this tag enables the developer to select the current value in the provided list, corresponding to the current value in the form.

LabelValueBean is a convenience class provided by Struts for just this purpose, but an html:select tag could iterate over a collection of any object you nominate, as long as the property and labelProperty attributes correspond to getter methods of that object. You will see an example of this tag in the "Example application" section toward the end of this chapter.

html:submit

This tag renders an HTML Submit button for the form.

<html:submit value="Save"/>

As well as the form elements of the HTML set of tags, Struts provides another set of tags that help render HTML elements. These tags are described in the following sections.

html:link

This is a useful tag for rendering a link to the specified URL:

<html:link page="/somepage.jsp" name="myMap">my link</html:link>

Developers can dynamically provide a list of parameter name-value pairs in order to append to the link, so the preceding example might render the following in plain HTML:

<a href="/somepage.jsp?param1=value1&param2=value2">my link</a>

where the parameter names and values are stored in a Map object added to the scope of this page, in this case represented by the bean myMap.

html:errors

This very useful tag renders either a collection of error messages placed within the scope of the page or an individual error message from that collection. The property attribute denotes the name of the error to be displayed. Not using the property attribute will result in all errors being displayed. An example of an ActionMessages collection of ActionMessage objects being placed within the scope of a JSP page using the saveErrors method was illustrated earlier in the login form example.

<html:errors property="name"/>

The display of this tag can be enhanced by placing some specifically named properties within the messages.properties file for this application. Including the following properties and their example values will mean that each error message displayed will be contained within an HTML unordered list, and that each element of the list will be red:

errors.header=<ul>
errors.prefix=<li><font color=red>
errors.suffix=</font></li>
errors.footer=</ul>

html:messages

There are two basic examples of this:

Example A:

<html:messages id="message">
    <bean:write name="message"/>
</html:messages>

Example B:

<html:messages id="message" property="welcomeNote">
    <bean:write name="message"/>
</html:messages>

This is similar to the html:errors tag but is used to reference ActionMessages added to a scope of the JSP page as an iterable collection (example A), or to access a specific message, as in example B, where the ActionMessage "welcomeNote" is printed out. These messages may have been saved in a Struts action using the saveMessages method.

html:javascript

Use this tag to render dynamic validation configured for the form bean nominated in the formName attribute. An example of how this is configured will be introduced in the next section. The staticJavascript attribute alerts the tag to allow the developer to include custom JavaScript entries, in addition to the dynamic scripts generated by the framework.

<html:javascript
      formName="loginForm"
      dynamicJavascript="true"
      staticJavascript="false"/>

The logic tags provided by Struts offer much of the functionality provided within the JSTL. Indeed, the Struts documentation recommends that the JSTL be used wherever possible in preference to the Struts tags.

The logic tags provided by Struts deal with conditional and iterative operations, such as looping over a collection of objects and testing the value of bean properties.

logic:equal

The logic:equal tags allow for the test of a property of a bean within a certain scope. In the following example, the LoginForm bean's username property is being tested. If the value results in "Nicholas", then the special message is displayed. All the attributes for this tag can utilize real-time expressions as values. This tag is equivalent to the c:if tag in JSTL.

<logic:equal name="loginForm"
             property="username"
             scope="request"

value="Nicholas">

    This is a special message for Nicholas.

</logic:equal>

logic:notEqual

This tag is the opposite of the logic:equal tag.

<logic:notEqual name="loginForm" property="username" value="Rupert">

This is a message for people who don't have Rupert as their username:

</logic:notEqual>

logic:match

This tag is used to test whether a property of a bean contains a substring, in this case uper. Other attributes such as location enable a substring match to be tested at a certain point in the property.

<logic:match name="loginForm" property="username" value="uper">
    This is special message for usernames with 'uper' in them
</logic:match>

logic:notMatch

This tag is basically the reverse of logic:match. The content is evaluated if the value being tested (in the property attribute) does not include as a substring the value of the value attribute.

<logic:notMatch name="loginForm" property="username" value="Jon">
    This is a special message for people without 'Jon' in their login name
</logic:notMatch>

logic:forward

This tag redirects the request to the global action forward nominated in the name attribute. The name attribute must refer to a configured global ActionForward entry.

<logic:forward name="error"/>

logic:redirect

This tag performs a redirect to a location it specifies. The three key attributes that specify that location are forward, href, and page. At least one of these must be specified. Parameters can be appended to the resulting URLs of these attributes by including a reference to a Map object of name-value pairs in the name attribute, similar to the html:link tag described earlier.

Alternatively, a single parameter can be added by specifying the name of the parameter in the paramId attribute and the corresponding value of the bean specified in the paramName attribute, as in the following example. Here, favouriteColor is a String bean whose value may resolve to red or blue and so on. The resulting URL would be /login.do?color=red.

<logic:redirect forward="error"/>
<logic:redirect name="myParameterMap" href="http://jakarta.apache.org/index.html"/>
<logic:redirect paramId="color" paramName="favouriteColor" page="/login.do"/>

logic:iterate

As the name suggests, the logic:iterate tag is used to iterate over its content for each item contained in the collection specified. The collection specified must be one of the following:

In the following example, the ArrayList used in the html:select example from earlier is used. The name of the bean referring to this collection is specified in the name attribute. The id element gives each member of the collection a name to refer to, scoped only within the boundaries of the tag. The type parameter tells the logic:iterate tag the class of the objects the collection contains. Each object is then accessed within the body of the tag by using the bean:write tag, which is explained in the next section. (For now, it just means "print this.")

<logic:iterate name="myList"
               id="thisElement"
               type="org.apache.struts.util.LabelValueBean">

   <bean:write name="thisElement" property="label"/> -
   <bean:write name="thisElement" property="value"/><br>

</logic:iterate>

This tag also supports various other convenient functions, such as starting the iteration at a certain index in the collection (offset attribute) and setting a maximum for the number of items that will be iterated over (length attribute).

logic:messagesPresent and logic:messagesNotPresent

There are two examples for this tag.

Example A:

<logic:messagesPresent property="name" message="false">
   <tr>
        <td><html:errors property="name"/></td>
   </tr>
</logic:messagesPresent>

Example B:

<logic:messagesNotPresent message="false">
   <tr>
       <td>So far, there have been no errors</td>
   </tr>
</logic:messagesNotPresent>

When messages are introduced to the scope of a JSP page, either as errors or as informational messages to the user, their presence, or absence, can be tested with these two complementary tags. In example A, the code is testing for the presence of an ActionMessage (assigned as an error—saveErrors) given the name "name". In example B, the code is testing for the absence of any message assigned as an error within the scope of the page.

These two examples relate specifically to errors added to the scope of the JSP page. What if the presence of normal informational messages (saveMessages) needs to be tested? By changing the message attribute to true, the test would restrict itself to just these messages.

An additional set of tags provided by Struts relates to the manipulation of bean objects within the JSP page. Much of the functionality provided here is also available via the JSTL tags. The Struts documentation recommends using the JSTL tags over the Struts tags wherever possible.

Strut's bean tags provide the capability to create and access objects or beans within a JSP page. The tags are designed to allow this interaction across the multiple scopes that are available: page, request, session, or application. The beans these tags provide for could come from within the JSP page or as objects made available by an action class.

bean:define

The bean:define tag is used to define and manipulate beans from or in any scope. This tag can be used in many capacities, three of which are illustrated by the following examples.

Example A:

<bean:define id="testVariable" value="This is a new String"/>
<bean:write name="testVariable" scope="page"/>

Example B:

<bean:define id="newSessionBean"
             name="testVariable"
             scope="page"
             toScope="session"/>
<bean:write name="newSessionBean" scope="session"/>

Example C:

<bean:define id="customerName" name="myCustomer" property="name" scope="request"/>

In the first example, a new String bean has been defined in the JSP page, and then its value has been rendered for display to the browser in the response using the bean:write tag.

In the second example, the bean created in example A has been copied as a new bean into the session scope, available via the id newSessionBean. It has been printed out using the bean:write tag as well, but this time telling the tag that the bean it is looking for is in the session scope.

In the final example, a Customer object has been added to the request scope of this JSP page. A property from this object has been defined as a new bean within the JSP page, called customerName. The use of the property attribute tells us that there must be a getName method in the customer object for this value to be accessed.

The bean:define tag is similar in some ways to the jsp:useBean tag.

bean:write

You saw some examples of bean:write tags in the previous set of examples. As is obvious by now, the bean:write tag is used to render values to the browser in the response. In addition to rendering text, this tag can also be used to format its output as desired. This is illustrated in the following example:

<bean:write name="customerName" scope="page"/>
<bean:write name="money" format="$###,###.00" ignore="true"/>

The bean:write tag has made use of its format attribute to determine how the value of a Float object should be displayed. If the Float object represented 100.2, then this tag would print out $100.20. The values to place in the format attribute use a formatting syntax common to some of the formatting objects available in the Java language. For more details on this syntax, have a look at the Java API documentation for the DecimalFormat or SimpleDateFormat classes.

This example also uses the ignore attribute. This indicates to the JSP compiler that should the money bean not be found in the designated scope, nothing should be printed. If this were left as the default false, a JSP compile error would result when this page first loaded and no money bean was found.

bean:include

The bean:include tag enables the response from a request to another Web resource to be the value of a new bean; in the following example this is called theAge. The external resource can be referenced using one of three attributes:

<bean:include id="theAge" href="http://www.theage.com.au"/>
<bean:write name="theAge"/>

bean:message

This is another tag that provides the capability to display internationalized messages from the resources provided by the application.

<bean:message key="application.name"/>

<bean:message key="application.welcome" arg0="Peter"/>

The first example has simply rendered a value from the messages.properties file for this application called application.name. The entry in messages.properties would be something like the following:

application.name=My Application

The second example shown also renders an entry in the messages.properties file but it adds a parameter to the message. This way, the JSP page can display messages from the messages.properties file with runtime data intermingled into the message. In this example, the application.welcome message is being displayed and the parameter "Peter" is being added using the attribute arg0. The definition of the application.welcome message in the messages.properties file would be as follows:

application.welcome=Welcome {0} to My Application

This would render on the browser as Welcome Peter to My Application. Very handy. Up to four arguments can be specified using the attributes arg0 through to arg4; these are replaced in the property using the {0}..{3} syntax to denote each parameter.

This section has introduced you to some of the more commonly used custom tags provided by Struts. It is by no means an exhaustive list; readers should consult the Struts documentation for that. What the documentation doesn't provide are clear concrete examples to solidify understanding. We hope that this discussion has achieved that for you.

Our tour through the Struts View layer is not yet over. The next section introduces some of the validation mechanisms available to application developers.

Form bean validation places the validation rules within the form bean class itself (LoginForm from the previous example). More specifically, it places it within a special method of the form bean that the Struts framework knows to call before the execute method of the Action class. The appropriate form bean and whether to call this special method are determined in the struts-config.xml file. Of course, this method does not apply to DynaActionBeans.

Here we build on the LoginForm example described earlier; the validation rules we may want to implement extend only to checking that the two fields, username and password, are not empty. With this knowledge, we can implement a validate method in the LoginForm class as follows:

...
public class LoginForm extends ActionForm
{
    private String _username;
    private String _password;

    public LoginForm()
    {
    }

...
    public ActionErrors validate(ActionMapping mapping,
        HttpServletRequest request)
    {
        ActionErrors errors = new ActionErrors();

        if ((_username == null) || (_username.length() < 1))
        {
            errors.add("username",
                new ActionMessage("error.login.username.missing"));
        }

        if ((_password == null) || (_password.length() < 1))
        {
            errors.add("password",
                new ActionMessage("error.login.password.missing"));
        }

        return errors;
    }
}

This new method is executed after the form is submitted but before the execute method of the LoginAction is invoked by the framework. If the ActionErrors object this class returns is null or empty, then processing continues on the LoginAction class as normal. If the ActionErrors object this method returns contains errors, then the input page that submitted the form is redisplayed and the values of the form are populated with what was originally entered. We should point out here the use of the ActionErrors object to house ActionMessages. ActionErrors is a subclass of ActionMessages. Some of the areas where ActionErrors have usually been used, such as in an Action class, have been deprecated in favor of the ActionMessages collection. For the time being, though, the validate method used here will need to return an ActionErrors collection. If you're using an older or a future version of Struts, make sure that you check the usage of these objects; otherwise, you may encounter problems. The Struts documentation alludes to a general theme of not using the ActionErrors object where possible, in favor of the ActionMessages object.

In the validate method in the previous code, the two fields _username and _password are checked to ensure they are not null and not empty, meaning that at least something has been typed in by the user. If either of the fields is found to be empty, a new error is added to the ActionErrors object. When adding the error to the ActionErrors object, the add method is used. This method, in this instance, takes two parameters. The first indicates the property for which this error applies. The second is the ActionMessage itself. The ActionMessage object is constructed with the name of an appropriate message property key available within the application. When the validate method returns a populated ActionErrors object to the input page, these messages are available to inform the user of what happened. To show these messages to the user, the html:errors custom tag is used:

...
<html:errors property="username"/><br>
Username: <html:text property="username"/><br>
<P>
<html:errors property="password"/><br>
Password: <html:password property="password"/><br>
...

In the preceding example, the code to display the appropriate error messages above the associated form element has been highlighted.

So how does the framework know which bean's validate method to invoke? And where is this input page thing? Let's recall the action-mapping in struts-config.xml for the LoginAction:

...
<action-mappings>
  <action path="/login"
          type="com.wrox.begjsp.ch19.struts.simpleform.LoginAction"
          name="loginForm"
          input="/login.jsp"
          validate="true"
          scope="request">
    <forward name="success" path="/welcome.jsp"/>
  </action>
</action-mappings>
...

The three attributes responsible for making this validation flow work have been highlighted. The name attribute indicates which form-bean entry maps to this action. The input attribute indicates the path that invoked this action (and where to go if an error occurs), and the validate attribute being set to true tells the framework that when this action is invoked, the validate method of the form-bean should be used.

As you can see, setting up basic form validation in this way is very simple and straightforward. It also ensures that the logic to do this for each interface is in one place and that the workflow from form submission to form error is clear and concise when reading the code. Of course, this is not the only way to implement framework-sponsored validation using Struts.

Using the form bean validation method means that all the validation logic, and in a big application it can be a lot of such logic, is localized in the ActionForm classes. Logic in this location is very difficult to change in a live application, and the person changing it must be a Java programmer. In response to these constraints, a more configurable validation mechanism has evolved.

The Struts Validator has evolved from a set of validation classes available under the Jakarta Commons project, and it has since been adopted into Struts 1.1 with some enhancements. Struts Validator places the validation rules for form beans inside an XML file, validation.xml. The rules defined in this XML file utilize a set of predefined validation mechanisms defined in a file provided by Struts, called validator-rules.xml. Put another way, the validation.xml file defines which rules will govern validation for forms and how they should behave, whereas validator-rules.xml defines these rules and references appropriate Struts objects to encapsulate the logic.

The validation provided by the Struts Validator can be called in two ways: on the client side or on the server side. Client-side validation is made possible by the fact that the validation rules provided by default with Struts also define equivalent JavaScript functions that can be placed on the page if required. This JavaScript is placed on the JSP page by using the Struts html:javascript tag:

<html:javascript dynamicJavascript="true"
                 formName="loginForm"/>

You can see from the preceding example that the dyanamicJavascript attribute of true indicates to the framework that the Validator-generated JavaScript should be placed here (you would put the tag above the HTML <body> tag). The formName attribute identifies the form bean to which the rules apply.

Leaving the preceding tag out of the JSP page leaves the validation to occur on the server side. In simple terms, each validation rule provided by Struts references an object that performs the validation based on the parameters it has been provided by the validation.xml file, and in so doing behaves almost exactly like the LoginForm validation that was implemented earlier.

The Struts Validator expects the form bean being validated to be of a certain type; therefore, the form bean used to represent the HTML form must now extend the org.apache.struts.validator.ValidatorForm (or org.apache.struts.validator.ValidatorActionForm) class instead of the ActionForm class.

If a DynaActionForm is currently being used, the org.apache.struts.validator.DynaValidatorForm (or org.apache.struts.validator.DynaValidatorActionForm) class must now be specified as the type attribute for the form-bean entry in the struts-config.xml file instead of the DynaActionForm class.

So how do we actually define the validation rules? First, the Struts Validator is a plug-in to Struts, so it must have a corresponding entry in the struts-config.xml file:

<plug-in className="org.apache.struts.validator.ValidatorPlugIn">
    <set-property property="pathnames"
                  value="/WEB-INF/validator-rules.xml,
                         /WEB-INF/validation.xml"/>
</plug-in>

This entry tells the framework where these two all-important files are located. The preceding entry places them in the /WEB-INF/ directory of the application.

As described, the validation.xml file tells the framework the rules that apply to each of the fields in each of the forms that the application uses. Let's look at the contents of this file for our login example. The validation rules implemented here specify that both of the fields, username and password, cannot be empty, i.e., that they are required:

<form-validation>
    <formset>
        <form name="loginForm">
          <field property="username" depends="required">
            <msg name="required" key="error.login.username.missing"/>
          </field>

          <field property="password" depends="required">
            <msg name="required" key="error.login.password.missing"/>
          </field>
        </form>
    </formset>
</form-validation>

The simple XML structure here is quite easy to read. The entry first defines a formset, the set of forms that this file defines validation for, and within this structure is a corresponding entry for each form. Within the form definition is an entry for each field of the form, and it is this entry that defines the validation rules and corresponding error messages for each of the form elements. Note the use of the depends attribute in the form element. In plain English, this would mean that this field depends on this rule. The depends attribute can also take a comma-separated list of rules that the field must satisfy. The nested msg element within the field entry nominates messages to be displayed for each of the rules specified in the depends attribute. Where no message is specified for a rule, the Struts Validator will search for a default message key in the messages.properties file. A list of these keys can be found in the validator-rules.xml file.

The required rule is a very simple one: The field is either empty or not. Other rules need variables to define their behavior, such as minlength. This rule ensures that the length of data placed in a field must be at least a certain length.

So what is the minimum length and how is this specified? Let's look at an example to explain this. If the login form needed the password to not only be required but also to be, for example, at least six characters long, the field entry would appear as follows:

<field property="password"
       depends="required,minlength">
 <msg name="required" key="error.login.password.missing"/>
 <msg name="minlength" key="error.login.password.length"/>
 <arg0 name="minlength" key="${var:minlength}" resource="false"/>
 <var>
        <var-name>minlength</var-name>
        <var-value>6</var-value>
 </var>
</field>

Whoa! Our simple validation entry just got a lot more complicated. Let's walk through this bit by bit. The field entry now depends on two rules: required and minlength:

<field property="password" depends="required,minlength">

A new error message has been added for cases when the minlength rule is broken:

<msg name="required" key="error.login.password.missing"/>
<msg name="minlength" key="error.login.password.length"/>

This is defined in the messages.properties file as follows:

error.login.password.length=The password must be {0} characters long

Note the parameter placeholder in the message. This is filled in by the next entry, an argument for the minlength msg entry:

<arg0 name="minlength" key="${var:minlength}" resource="false"/>

This passes a value to the error message for the minlength rule. The parameter passed to the message is represented by the value specified in the key attribute. And as with parameters passed in the html:message tag described earlier, up to four arg parameters (arg0 ... arg3) can be used. In this case, the value is actually a reference to the next entry, where the minlength rule variable is specified:

<var>
    <var-name>minlength</var-name>
    <var-value>6</var-value>
</var>

One of the strengths of the Struts Validator is that it allows for some very sophisticated validation logic to be implemented, even when just using the default set of validation rules provided by Struts. Following is a list of the other rules that can be used with the default validator-rules.xml:

The mask rule takes one variable, the mask regular expression to be tested.

As you can see, the validation rules provided by the Struts Validator can be very sophisticated and cover many common scenarios required by applications. If you find that the default set of rules does not satisfy your scenario, then you might consider adding your own Validator. The Struts documentation provides some brief instructions on doing this. Unfortunately, this topic is out of the scope of this book.

Struts doesn't provide a mechanism to validate the business rules of an application simply because it shouldn't or can't. Rather, the breadth of validation required to ensure that the business rules of an application are kept in check is beyond the scope of an application framework like Struts. All the framework can do, and Struts does this admirably, is to provide a structure and infrastructure within which such rules can be tested, and if broken, dealt with.

One common strategy used in Struts applications is to perform the form element validation in the ways just described and to perform, or call on, business logic validation within the actions themselves.

Suppose you have a system dealing with new customer registration. The validation you need to implement falls into the two categories identified: The general form validation would cover problems such as empty fields, passwords that are not complicated enough, or invalid e-mail addresses. The business logic validation would cover more involved problems such as a login name that is already taken by another customer, or an invalid ZIP code

The register customer form would submit to an appropriate action, maybe saveNewCustomer.do (SaveNewCustomerAction class). Within the execute method of this class, other objects developed for the application could be called to do the appropriate checks and then return a List of error message keys back to the Action class. These error message keys would then be added to an ActionMessages object in the way you have already seen.

The key objectives you want to achieve in structuring business logic validation in this way are as follows:

The preceding example is just one suggestion for how such validation could be dealt with; there would literally be millions out there. It is a testament to the flexibility of Struts that it enables applications to be implemented in many different ways.

This concludes the discussion about the different layers of an MVC application developed using the Struts framework. A lot has been covered in this section, so it may be helpful to briefly recap the main points before moving on to the examples.

In the Controller layer, you saw the role that the ActionServlet and Action classes play in defining the flow of an application. You also learned how Struts encapsulates HTML forms with ActionForm and DynaActionForm beans. The Model layer was defined within the structure of an application, and it was ascertained that Struts doesn't play a big part in defining its use and architecture.

In the View layer, many points were covered. You first saw how the ActionForm and DynaActionForm beans can interact with the elements of an HTML form. Internationalization was then discussed, with reference to messages provided to the user. You also took a look at the Struts Tag Library, and saw how some of the more commonly used tags were applied. The View discussion was rounded off with validation techniques using Struts and a suggestion for how business logic may be implemented.