Tag that generates HTML form fields of type <input type="button" ... /> which render buttons for submitting forms. The only capability offered above and beyond a pure html tag is the ability to lookup the value of the button (i.e. the text on the button that the user sees) from a localized resource bundle.

The tag will set it's value using the first non-null result from the following list:

• formName.buttonName from the localized resource bundle
• buttonName from the localized resource bundle
• the body of the tag
• the value attribute of the tag

Implements an HTML tag that generates form fields of type <input type=" checkbox"/>. Since a single checkbox widget on a HTML page can have only a single value, the value tag attribute must always resolve to a scalar value which will be converted to a String using the Stripes Formatting system, or by caling toString() if an appropriate Formatter is not found.

Checkboxes perform automatic (re-)population of state. They prefer, in order, values in the HttpServletRequest, values in the ActionBean and lastly values set using checked="" on the page. The "checked" attribute is a complex attribute and may be a Collection, an Array or a scalar Java Object. In the first two cases a check is performed to see if the value in the value="foo" attribute is one of the elements in the checked collection or array. In the last case, the value is matched directly against the String form of the checked attribute. If in any case a checkbox's value matches then a checked="checked" attribute will be added to the HTML written.

The tag may include a body and if present the body is converted to a String and overrides the checked tag attribute.

Outputs validation errors. If an action attribute is specified, will only render errors if the submitted form action matches the specified one. Otherwise, if nested inside a stripes form tag, will only display errors if they are for the enclosing form. Otherwise will display errors for whatever form was submitted. Can optionally take a field name to limit output to a single field's errors.

By default will output a simple header followed by a list of validation errors in an HTML unordered list. This behaviour can be customized in two ways. The first will affect the default output of the errors tag on all pages within the application. The errors tag will consult the error messages resource bundle (probably StripesResources.properties unless you have configured it differently) for four String resources which it will use to construct the output. The four properties, and their default values are:

• stripes.errors.header=<div class="errorHeader">Validation Errors</div><ul>
• stripes.errors.footer=</ul>
• stripes.errors.beforeError=<li>
• stripes.errors.afterError=</li>

The second way to customize the output affects only the output on a specific page. The nestable tags are: stripes:individual-error, stripes:error-header and stripes:error-footer. An example, re-creating the default output using this technique follow:

<stripes:errors>
     <stripes:errors-header><div class="errorHeader">Validation Errors</div><ul></stripes:errors-header>
     <li><stripes:individual-error/></li>
     <stripes:errors-footer></ul></stripes:errors-footer>
</stripes:errors>

Tag that generates HTML form fields of type <input type="file" ... />. The only functionality provided above and beyond a straight HTML input tag is that the tag will find its enclosing form tag and ensure that the for is set to POST instead of GET, and that the encoding type of the form is properly set to multipart/form-data as both these settings are necessary to correctly perform file uploads.

Does not perform repopulation because default values for <input type="file"/> are not allowed by the HTML specification. One can only imagine this is because a malicous page author could steal a user's files by defaulting the value and using JavaScript to auto-submit forms! As a result the tag does not accept a body because it would have no use for any generated content.

Generates one or more <input type="hidden" ... /> HTML tags based on the value supplied. The hidden tag assigns the value attribute by scanning in the following order:

• for one or more values with the same name in the HttpServletRequest
• for a field on the ActionBean with the same name (if a bean instance is present)
• by collapsing the body content to a String, if a body is present
• referring to the result of the EL expression contained in the value attribute of the tag.

The result of this scan can produce either a Collection, an Array or any other Object. In the first two cases the tag will output an HTML hidden form field tag for each value in the Collection or Array. In all other cases the Object is toString()'d (unless it is null) and a single hidden field will be written.

Label tag that can look up localized field labels and render differently when the labelled field is in error. While the label field is usually used to generated form field labels, it can be used to generate HTML label tags with arbitrary localized or non-localized values.

It is important to understand the relationship between the name and for attributes of the stripes:label tag. The for attribute is used directly to generated the for attribute of the generated HTML label tag, and as such should correspond to the HTML id attribute of the input tag for which it is a label. If the name attribute is omitted then the value of the for attribute will also be used as the name attribute.

The value of the label is set by searching for a non-null value in the following order:

• {formAction}.{name} in the form field localization bundle
• {name} in the form field localization bundle
• The body of the label tag
• A warning message telling you to supply a label value somewhere!

In the case of indexed or mapped form fields (e.g. foo[3].bar) the indexing and mapping will be removed from the name prior to using it to lookup labels (e.g. foo.bar). This is done to remain consistent with the way field names are looked up for error messages.

It should be noted that in cases where a form field and HTML control are one-to-one (e.g. text, password, select) the name of the label will usually equal the name of the control. However, this need not be the case. You may use any value for the name of the label, but the label will only perform error rendering correctly if the name is equal to the name of the form field being labelled. To illustrate this point consider the following example:

<th>
    <stripes:label for="bug.status"/>:
</th>
<td>
	<c:forEach var="status" items="<%=Status.values()%>">
		<stripes:radio id="bug.status.${stripes:enumName(status)}"
		               name="bug.status"
		               value="${stripes:enumName(status)}"/>
		<stripes:label for="bug.status.${stripes:enumName(status)}">
			${stripes:enumName(status)}
		</stripes:label>
	</c:forEach>
</td>

The above example uses one label tag at the top (with for="bug.status") that labels a row in the table and will display differently when the bug.status field is in error. It then employs a label tag for each radio button. These are bound to the individual radio buttons (clicking on the label will select the appropriate radio button), and default to the name of the enum value if a localized name isn't found. Since these labels do not match the field name exactly, they will not render differently when the field is in error.

Tag that generates HTML links, used for linking to pages and ActionBean events within a Stripes application. Works in concert with zero or more nested link-param tags in order to allow addition of arbitrary parameters to any URL. The body of the tag, minus any link-param tags, is trimmed for whitespace at either end, and is then used as the contents of the link body.

Generates an <option value="foo">Fooey</option> HTML tag. Coordinates with an enclosing select tag to determine it's state (i.e. whether or not it is selected.) As a result some of the logic regarding state repopulation is a bit complex.

Since options can have only a single value per option the value attribute of the tag must be a scalar, which will be converted into a String using a Formatter if an appropriate one can be found, otherwise the toString() method will be invoked.The presence of a "selected" attribute is used as an indication that this option believes it should be selected by default - the value (as opposed to the presence) of the selected attribute is never used....

The option tag delegates to its enclosing select tag to determine whether or not it should be selected. See the stripes:select for documentation on how it determines selection status. If the select tag has no opinion on selection state (note that this is not the same as select tag deeming the option should not be selected) then the presence of the selected attribute (or lack thereof) is used to turn selection on or off.

If the option has a body then the String value of that body will be used to generate the body of the generated HTML option. If the body is empty or not present then the label attribute will be written into the body of the tag.

Writes a set of <option value="foo">bar</option> tags to the page based on the contents of a Collection. Each element in the collection is represented by a single option tag on the page. Uses the label and value attributes on the tag to name the properties of the objects in the Collection that should be used to generate the body of the HTML option tag and the value attribute of the HTML option tag respectively. If either (or both) of the label or value properties are ommitted the item itself will be used for the label/value instead - this is done to support collections of simple types like Strings and Numbers.

E.g. a tag declaration that looks like:

<stripes:options-collection collection="${cats}" value="catId" label="name"/>

would cause the container to look for a Collection called "cats" across the various JSP scopes and set it on the tag. The tag would then proceed to iterate through that collection calling getCatId() and getName() on each cat to produce HTML option tags.

All other attributes on the tag (other than collection, value and label) are passed directly through to the stripes:option tag which is used to generate the individual HTML options tags. As a result the stripes:options-collection will exhibit the same re-population/selection behaviour as the regular options tag.

Since the tag has no use for one it does not allow a body.

Writes a set of <option value="foo">bar</option> tags to the page based on the values of a enum. Each value in the enum is represented by a single option tag on the page. The options will be generated in ordinal value order (i.e. the order they are declared in the enum). Uses the label attribute on the tag to name the property of the enum that should be used to generate the body of the HTML option tag. If the label attribute is not set then the tag will call toString() on the enum value and use that as the body of the tag.

E.g. a tag declaration that looks like:

<stripes:options-enumeration collection="net.kitty.EyeColor"/>}

would result in the tag attempting to invoke Class.forName("net.kitty.EyeColor") and cast the result to type Class<Enum>. If that fails, a JspException will be raised. The tag will then proceed to call name() in order to fetch the value of the enum and use that for the value of the option, and call toString() to provide the body of the option because a label attribute was not specified.

All other attributes on the tag (other than enum and label) are passed directly through to the stripes:option which is used to generate the individual HTML options tags. As a result the stripes:options-enumeration will exhibit the same re-population/selection behaviour as the regular option tag.

Since the tag has no use for one it does not allow a body.

Tag that generates HTML form fields of type <input type="password" name="foo" value="bar"/>, which can optionally re-populate their value, and provide error display/formatting consistent with the rest of the Stripes input tags. Password tags may have only a single value, whose default may be set using either the body of the tag, or using the value="" attribute of the tag. At runtime the contents of the text field are determined by looking first for a non-null body and if one is not found, then a non-null value attribute.

Repopulation of values for password tags is optional, and by default is not performed. To control this behaviour explicitly use the repopluate tag attribute.

Generates <input type="radio" value="foo"/> HTML tags based on the attribute set on the tag and the state of the form. Since a single radio button widget on a HTML page can have only a single value, the value tag attribute must be a Scalar object. The value will be converted to a String using the Stripes formatting system (with appropriate defaults), or by calling toString if an appropriate Formatter does not exist. Similarly since radio button sets can have only a single selected value at a time the checked attribute of the tag must also be a scalar value.

Radio buttons perform automatic (re-)population of state. They prefer, in order, the value in the HttpServletRequest, the value in the ActionBean and lastly the valuee set using checked="" on the page. If the value of the current radio button matches the checked value from the preferred source then the attribute checked="checked" will be written in the HTML tag.

The tag may include a body and if present the body is converted to a String and overrides the checked tag attribute.

Tag that generates HTML form fields of type <input type="reset" ... /> which render buttons for resetting forms. The only capability offered above and beyond a pure html tag is the ability to lookup the value of the button (i.e. the text on the button that the user sees) from a localized resource bundle.

The tag will set it's value using the first non-null result from the following list:

• formName.buttonName from the localized resource bundle
• buttonName from the localized resource bundle
• the body of the tag
• the value attribute of the tag

Coordinates with one or more other tags to produce a well formed HTML select tag with state repopulation. The select tag itself really only writes out the basic <select> name="foo"> ... </select> piece of the structure, and provides mechanisms for child options to determine whether or not they should render themselves as selected.

Tag that generates HTML form fields of type <input type="submit" ... /> which render buttons for submitting forms. The only capability offered above and beyond a pure html tag is the ability to lookup the value of the button (i.e. the text on the button that the user sees) from a localized resource bundle.

The tag will set it's value using the first non-null result from the following list:

• formName.buttonName from the localized resource bundle
• buttonName from the localized resource bundle
• the body of the tag
• the value attribute of the tag

Tag that generates HTML form fields of type <input type="text" name="foo" value="bar"/>, which can dynamically re-populate their value. Text tags may have only a single value, whose default may be set using either the body of the tag, or using the value="" attribute of the tag. At runtime the contents of the text field are determined by looking for the first non-null value in the following list:

• A value with the same name in the HttpServletRequest
• A value on the ActionBean if an ActionBean instance is present
• The contents of the body of the tag
• The value attribute of the tag

Tag that generates HTML form fields of type <textarea name="foo"> ... </textarea>, which can dynamically re-populate their value. Textareas may have only a single value, whose default may be set using either the body of the textarea, or using the value="" attribute of the tag. At runtime the contents of the textarea are determined by looking for the first non-null value in the following list:

A value with the same name in the HttpServletRequest A value on the ActionBean if an ActionBean instance is present The contents of the body of the textarea The value attribute of the tag

Puts the ActionBean with the specified binding into page context under the supplied name. If the ActionBean does not already exist, it will be instantiated and binding will be run to bind values from the HttpServletRequest onto the ActionBean. Validation will not be run, and any error messages produced from the binding/type conversion process will be discarded. The ActionBean will then be placed in request scope, just as done by the DispatcherServlet.

If the ActionBean did not previously exist, and an event is specified, the event handler will be executed on the ActionBean. If the ActionBean already existed, supplying the event attribute has no effect.

Lastly, if the var or id attribute is supplied (they are synonymous and only one should be supplied) the ActionBean is bound in to page context using the name supplied. This is true in all cases, regardless of whether the ActionBean is newly instantiated, or pre-existing. This allows the tag to be used to provide an easier name for the ActionBean than referring to it by binding.

Examines the request and include hidden fields for all parameters that have do not have form fields in the current form. Will include multiple values for parameters that have them. Excludes 'special' parameters like the source page parameter, and the paramter that conveyed the event name.

Very useful for implementing basic wizard flow without relying on session scoping of ActionBeans, and without having to name all the parameters that should be carried forward in the form.

Defines a reusable layout. This tag is designed to wrap the entire contents of a JSP that is to be re-used to manage the layout of multiple pages. It can contain HTML, JSP content, scriptlets etc. It may also contain stripes:layout-component tags. The stripes:layout-component names a section of the layout that can be supplied during rendering (it may be empty, or have default contents).

Layout definitions will also have access to, through PageContext, any attributes/parameters supplied at rendering time. These can be referenced in the layout definition using EL, for example as ${myCustomParameter}. This allows layouts not only to templatize look and feel, but to potentially render differently based on the values of parameters passed in at rendering time.

Used to define or supply a component of a layout. The stripes:layout-component tag can be nested inside both the stripes:layout-definition and stripes:layout-render tags. In the former case it defines a named component in the layout, and the (optional) body provides a default for the component. When nested in a stripes:layout-render tag, the body overrides the named component defined in the layout.

The vanilla case would be to have a layout which defines the header/footer etc. for your site and that has a component named "body" or "contents" or something similar, which wraps the area where page content would normally be displayed. Then, when using that layout through a stripes:layout-render tag, you would use a stripes:layout-component tag to provide a value for the "body" or "contents" component of the layout.

Renders the named layout, supplying it with any specified parameters and overridden components. In addition to being able to supply nested stripes:layout-component tags, you may also supply any number of dynamic or arbitrary parameters to this tag. All parameters (except name) will be made available to the layout definition through the page context.