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): http://stripes.sourceforge.net/docs/current/taglib/
- Using tags to display Errors
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:
|Standard Tag Library||<%@ taglib prefix="stripes" uri="http://stripes.sourceforge.net/stripes.tld" %>|
|DynAttr Tag Library||<%@ taglib prefix="stripes" uri="http://stripes.sourceforge.net/stripes-dynattr.tld" %>|
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:
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.
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:
- The HttpServletRequest parameter map for values matching the name of the input tag
- The ActionBean for a property or nested property matching the name of the input tag
- 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:
- If the field in question has errors, revert to the DefaultPopulationStrategy
- Otherwise if an ActionBean is present and has a matching property, use it's value even if it is null
- Otherwise look for a non-null value specified on the page
- 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:
Configuring the alternative population strategy is as simple as adding an initialization parameter for the StripesFilter, e.g.