Tag Library Doc

This page contains high level information about the Stripes tag library. Other more detailed sources of information concerning the tag library include:

• Generated tag library documentation (using TLDDoc): https://stripesframework.ci.cloudbees.com/job/Stripes%20Master/ws/stripes/target/site/tlddoc/index.html
• Using tags to display Errors

Usage

Stripes includes two Tag Library Descriptors inside the stripes.jar contained within the Stripes distribution. To use the Stripes tag library simply ensure that stripes.jar is located in your web applications /WEB-INF/lib directory, and include the following line at the top of your JSP file:

Dynamic Attributes

The Stripes standard tag library does not permit the use of non-standard attributes for an tag that is the analog of an HTML tag, for example <stripes:text>. As a result they also do not allow dynamic attributes (dynamic attributes are a JSP system for accepting arbitrary attributes who's names are not know when the tag is written). The primary reason for this is to cut down on runtime errors for JSP developers. Most modern IDEs will catch mistakes in tag attributes and alert the developer. A fairly benign example might be:

<stripes:submit name="save" onlick="validate(this)"/>

With dynamic attributes disabled IDEs and JSP compilers will catch this error. With dynamic attributes enabled they will not, as it is valid (just not what the developer intended.

However with the advent of AJAX and JavaScript libraries it is sometimes desirable to use non-HTML attributes in HTML tags. For the reasons outlined above Stripes includes two slightly different TLDs that can be used. The standard one does not allow dynamic attributes in HTML tags and should be used in most cases. The second one allows dynamic attributes. It is possible (even recommended) to use both TLDs in one page. Doing so will allow the standard library to be used where possible, and the dynamic attribute one only where absolutely necessary. E.g.:

<%@ taglib prefix="s" uri="http://stripes.sourceforge.net/stripes.tld" %>
<%@ taglib prefix="d" uri="http://stripes.sourceforge.net/stripes-dynattr.tld" %>

<s:form action="/my/NewsSearch.action">
	<s:text name="keywords"/>
	<d:text name="publicationDate" dojoType="calendar"/>
	<s:submit name="search"/>
</s:form>

Input Tag Population and Repopulation

The Stripes input tags (those that generate form form fields) are designed to be able to pre-populate and re-populate their own values based on values in the request, the ActionBean and values specified on the page. The order in which various sources are checked when populating a tag's value is determined by the configured PopulationStrategy. Unless otherwise configured Stripes uses an instance of DefaultPopulationStrategy for this purpose.

The DefaultPopulationStrategy searches in the following order for the first non-null value(s) when populating a given input tag:

1. The HttpServletRequest parameter map for values matching the name of the input tag
2. The ActionBean for a property or nested property matching the name of the input tag
3. The value specified by the tag itself (varies by tag; usually as a value attribute, or as the body of the tag)

The reasoning behind this is as follows:

• What the user entered should take precedence when re-displaying input to that same user
• Values in the ActionBean usually represent domain values, and are common sources or pre-population
• Values on the page are usually defaults specified for when no other applicable value is present

Stripes also includes a second population strategy called BeanFirstPopulationStrategy. The semantics of this population strategy are quite different - it's search strategy is:

1. If the field in question has errors, revert to the DefaultPopulationStrategy
2. Otherwise if an ActionBean is present and has a matching property, use it's value even if it is null
3. Otherwise look for a non-null value specified on the page
4. And lastly, look for a non-null value in the HttpServletRequest

If neither of these strategies meets your needs, worry not! It is very easy to change this behaviour - the DefaultPopulationStrategy was built with subclassing in mind. It provides individual methods to fetch an approprate value for the tag from the request, from the ActionBean and from the tag itself. It also contains a helper method to determine if the form is in error - in case it is desirable to modify behaviour based on error state. In order to change the PopulationStrategy all you need to do is subclass the DefaultPopulationStrategy and override the getValue(InputTagSupport tag) method to search in a different order. An example class is below:

public class MyPopulationStrategy extends DefaultPopulationStrategy {
	/** Strategy to look at the ActionBean first, then the request, then the page.*/
	public Object getValue(InputTagSupport tag) throws StripesJspException {
		Object value = getValueFromActionBean(tag);
		if (value==null) value = getValuesFromRequest(tag);
		if (value==null) value = getValueFromTag(tag);

	return value;
	}
}

Configuring the alternative population strategy is as simple as adding an initialization parameter for the StripesFilter, e.g.

....
<init-param>
	<param-name>PopulationStrategy.Class</param-name>
	<param-value>com.myco.web.MyPopulationStrategy</param-value>
</init-param>
....