JSP and JSTL

The form tag library comes bundled in spring-webmvc.jar. The library descriptor is called spring-form.tld.

To use the tags from this library, add the following directive to the top of your JSP page:

where form is the tag name prefix you want to use for the tags from this library.

This tag renders an HTML 'form' element and exposes a binding path to inner tags for binding. It puts the command object in the PageContext so that the command object can be accessed by inner tags. All the other tags in this library are nested tags of the form tag.

Assume that we have a domain object called User. It is a JavaBean with properties such as firstName and lastName. We can use it as the form-backing object of our form controller, which returns form.jsp. The following example shows what form.jsp could look like:

The firstName and lastName values are retrieved from the command object placed in the PageContext by the page controller. Keep reading to see more complex examples of how inner tags are used with the form tag.

The following listing shows the generated HTML, which looks like a standard form:

The preceding JSP assumes that the variable name of the form-backing object is command. If you have put the form-backing object into the model under another name (definitely a best practice), you can bind the form to the named variable, as the following example shows:

This tag renders an HTML input element with the bound value and type='text' by default. For an example of this tag, see The Form Tag. You can also use HTML5-specific types, such as email, tel, date, and others.

This tag renders an HTML input tag with the type set to checkbox.

Assume that our User has preferences such as newsletter subscription and a list of hobbies. The following example shows the Preferences class:

The corresponding form.jsp could then resemble the following:

There are three approaches to the checkbox tag, which should meet all your checkbox needs.

Note that, regardless of the approach, the same HTML structure is generated. The following HTML snippet defines some checkboxes:

You might not expect to see the additional hidden field after each checkbox. When a checkbox in an HTML page is not checked, its value is not sent to the server as part of the HTTP request parameters once the form is submitted, so we need a workaround for this quirk in HTML for Spring form data binding to work. The checkbox tag follows the existing Spring convention of including a hidden parameter prefixed by an underscore (_) for each checkbox. By doing this, you are effectively telling Spring that “the checkbox was visible in the form, and I want my object to which the form data binds to reflect the state of the checkbox, no matter what.”

This tag renders multiple HTML input tags with the type set to checkbox.

This section build on the example from the previous checkbox tag section. Sometimes, you prefer not to have to list all the possible hobbies in your JSP page. You would rather provide a list at runtime of the available options and pass that in to the tag. That is the purpose of the checkboxes tag. You can pass in an Array, a List, or a Map that contains the available options in the items property. Typically, the bound property is a collection so that it can hold multiple values selected by the user. The following example shows a JSP that uses this tag:

This example assumes that the interestList is a List available as a model attribute that contains strings of the values to be selected from. If you use a Map, the map entry key is used as the value, and the map entry’s value is used as the label to be displayed. You can also use a custom object where you can provide the property names for the value by using itemValue and the label by using itemLabel.

This tag renders an HTML input element with the type set to radio.

A typical usage pattern involves multiple tag instances bound to the same property but with different values, as the following example shows:

This tag renders multiple HTML input elements with the type set to radio.

As with the checkboxes tag, you might want to pass in the available options as a runtime variable. For this usage, you can use the radiobuttons tag. You pass in an Array, a List, or a Map that contains the available options in the items property. If you use a Map, the map entry key is used as the value and the map entry’s value are used as the label to be displayed. You can also use a custom object where you can provide the property names for the value by using itemValue and the label by using itemLabel, as the following example shows:

This tag renders an HTML input tag with the type set to password with the bound value.

Note that, by default, the password value is not shown. If you do want the password value to be shown, you can set the value of the showPassword attribute to true, as the following example shows:

This tag renders an HTML 'select' element. It supports data binding to the selected option as well as the use of nested option and options tags.

Assume that a User has a list of skills. The corresponding HTML could be as follows:

If the User’s skill are in Herbology, the HTML source of the 'Skills' row could be as follows:

This tag renders an HTML option element. It sets selected, based on the bound value. The following HTML shows typical output for it:

If the User’s house was in Gryffindor, the HTML source of the 'House' row would be as follows:

This tag renders a list of HTML option elements. It sets the selected attribute, based on the bound value. The following HTML shows typical output for it:

If the User lived in the UK, the HTML source of the 'Country' row would be as follows:

As the preceding example shows, the combined usage of an option tag with the options tag generates the same standard HTML but lets you explicitly specify a value in the JSP that is for display only (where it belongs), such as the default string in the example: "-- Please Select".

The items attribute is typically populated with a collection or array of item objects. itemValue and itemLabel refer to bean properties of those item objects, if specified. Otherwise, the item objects themselves are turned into strings. Alternatively, you can specify a Map of items, in which case the map keys are interpreted as option values and the map values correspond to option labels. If itemValue or itemLabel (or both) happen to be specified as well, the item value property applies to the map key, and the item label property applies to the map value.

This tag renders an HTML textarea element. The following HTML shows typical output for it:

This tag renders an HTML input tag with the type set to hidden with the bound value. To submit an unbound hidden value, use the HTML input tag with the type set to hidden. The following HTML shows typical output for it:

If we choose to submit the house value as a hidden one, the HTML would be as follows:

This tag renders field errors in an HTML span element. It provides access to the errors created in your controller or those that were created by any validators associated with your controller.

Assume that we want to display all error messages for the firstName and lastName fields once we submit the form. We have a validator for instances of the User class called UserValidator, as the following example shows:

The form.jsp could be as follows:

If we submit a form with empty values in the firstName and lastName fields, the HTML would be as follows:

What if we want to display the entire list of errors for a given page? The next example shows that the errors tag also supports some basic wildcard functionality.

The following example displays a list of errors at the top of the page, followed by field-specific errors next to the fields:

The HTML would be as follows:

The spring-form.tld tag library descriptor (TLD) is included in the spring-webmvc.jar. For a comprehensive reference on individual tags, browse the API reference or see the tag library description.

A key principle of REST is the use of the “Uniform Interface”. This means that all resources (URLs) can be manipulated by using the same four HTTP methods: GET, PUT, POST, and DELETE. For each method, the HTTP specification defines the exact semantics. For instance, a GET should always be a safe operation, meaning that it has no side effects, and a PUT or DELETE should be idempotent, meaning that you can repeat these operations over and over again, but the end result should be the same. While HTTP defines these four methods, HTML only supports two: GET and POST. Fortunately, there are two possible workarounds: you can either use JavaScript to do your PUT or DELETE, or you can do a POST with the “real” method as an additional parameter (modeled as a hidden input field in an HTML form). Spring’s HiddenHttpMethodFilter uses this latter trick. This filter is a plain Servlet filter and, therefore, it can be used in combination with any web framework (not just Spring MVC). Add this filter to your web.xml, and a POST with a hidden method parameter is converted into the corresponding HTTP method request.

To support HTTP method conversion, the Spring MVC form tag was updated to support setting the HTTP method. For example, the following snippet comes from the Pet Clinic sample:

The preceding example performs an HTTP POST, with the “real” DELETE method hidden behind a request parameter. It is picked up by the HiddenHttpMethodFilter, which is defined in web.xml, as the following example shows:

The following example shows the corresponding @Controller method:

The Spring form tag library allows entering dynamic attributes, which means you can enter any HTML5 specific attributes.

The form input tag supports entering a type attribute other than text. This is intended to allow rendering new HTML5 specific input types, such as email, date, range, and others. Note that entering type='text' is not required, since text is the default type.