Strut your stuff with JSP tags
Use and extend the open source Struts JSP tag library
One great benefit of JSP and J2EE is that they enable the developer community to speak a common language. The downside of those technologies is that they sometimes require a lot of mindless coding more suitable for a machine than a human being. That is particularly true in today’s big e-commerce projects with their huge teams and tight deadlines. In such situations everyone reverts to simple and safe procedures — the most advanced form of reuse being cut and paste. There is simply no time for experimentation. Fortunately, JSP allows more advanced forms of reuse to be imported from third parties in the form of custom tag libraries. This article focuses on one such library, the open source Struts tag library, and presents extensions that ease your coding effort.
The Struts package, which is part of the open source Jakarta project, provides a well-thought-out MVC (model-view-controller) framework that many projects would do well in adapting at the start of their Website development. The custom tags represent the view part of that framework, but it is perfectly feasible to use the tags without the model and controller part.
Most of the tags defined by Struts help associate bean properties with form fields. That greatly reduces the complexity of writing forms that remember all user choices between requests. That is particularly true for complex tags such as the standard select tag, in which plain JSP code to restore the user’s choice can get quite bulky.
Even with Struts’s custom tags there remain two time-consuming and tedious tasks you must do for the page bean: you must write properties that hold the user input between requests and implement user input validation and error message display. This article presents techniques to deal with those tasks. The use of automatic properties alleviates the creation of all page bean properties that primarily serve to remember user input when the page has to be redisplayed, either because it had errors or because the user wanted to review a previous step in a multipage transaction. Validation with regular expressions greatly simplifies the validation of user input and the display of appropriate error messages. The amount of code needed to implement those techniques is surprisingly small and can be found in the code listings in this article.
The following image shows a page that uses both techniques:
Listing 1 shows the JSP behind this form. Some table and font formatting has been removed for clarity, so the page would look a bit jagged and less colorful but otherwise just like the above figure.
Listing 1. transfer.jsp: The transfer form
<%@ taglib uri="/WEB-INF/struts.tld" prefix="struts" %>
<jsp:useBean id="transfer" scope="session" class="com.bank.PageBean"/>
<%
org.apache.struts.util.BeanUtils.populate(transfer, request);
if(request.getParameter("marker") == null)
// initialize a pseudo-property
transfer.set("days", java.util.Arrays.asList(
new String[] {"1", "2", "3", "4", "31"}));
else
if(transfer.validate(request))
%><jsp:forward page="transferConfirm.jsp"/><%
%>
<html>
<head>
<title>MyBank - Transfer</title>
</head>
<body>
<H2> Money Transfer </H2>
<struts:form name="transfer" type="com.bank.PageBean"
action="transfer.jsp" method="post">
<struts:hidden property="marker"/>
Receiver:
<struts:text property="receiver" pattern="@personName"
errorMessage="@personName"/>
<%= transfer.getError("receiver") %><br>
Account:
<struts:text property="destAccount" pattern="/^[0-9]{7,9}$/"
errorMessage="Account can have 7 and 9 digits"/>
<%= transfer.getError("destAccount") %><br>
Amount:
<struts:text property="amount" pattern="@amount"
errorMessage="Amount can have 8 digits plus two decimals" />
<%= transfer.getError("amount") %><br>
Date:
<struts:select property="day">
<struts:options property="days"/>
</struts:select><br>
<struts:submit value="submit"/>
</struts:form>
</body>
</html>
The page bean, specified in the useBean tag and in the Struts form tag, is completely generic. It knows nothing about that particular form, neither the names of the fields nor the constraints on their contents. All that information comes from the JSP page. In many cases, though, the basic bean would be extended to, for example, communicate with the back end, perhaps through JDBC, CORBA, or EJBs.
Let’s take a short walk through the JSP code in Listing 1. First the taglib tag at the top says where to find a file describing the syntax of any tags prefixed with “struts:”. Then the useBean tag creates a scripting variable named “transfer” of class PageBean and associates it with any previously used bean of the same name, class, and scope. If no such bean exists, then it is created.
Next you see a scriptlet that represents the controller code for that page. Having the controller code on the JSP page goes against the separation of code and content but helps keep this example short. The form on the page thus uses the page itself as a target, so this same page will be called when the form is submitted.
The scriptlet starts by populating the bean properties with the request data (if any). Then the presence of the marker parameter is used to detect if that is the initial page request or a subsequent form submit request. If that is the initial request, the days property for the options tag is initialized. If, on the other hand, that is a subsequent submission of the form, then a validation function is called and, if it succeeds, control is forwarded to the next page in the transaction.
The Struts tags are next. The form tag specifies that the transfer bean is where all the enclosed field tags should look for properties. Each of the three text tags specifies which transfer property should be used for initialization, to which regular expression pattern the user’s input should be compared, and what should be displayed if the input doesn’t match the pattern. A pattern or an error message starting with “@” denotes a predefined string. If the users input fails to match the pattern, the expressions
<%= transfer.getError(fieldname) %>
will display the error messages when the page is redisplayed for correction. Finally, the select tag lets the user select any item in the list specified in the options tag. The initial selection is the value of the day property, which also receives the value that the user selects.
Let’s now examine the changes you need to make to the Struts library for that to work.
Automatic properties
Automatic properties are to JSP what dynamic variables are to a programming language. In a programming language that supports them, you can use dynamic variables without declaring them first. Similarly, you can use automatic properties on a JSP page without defining them with set and get methods. Automatic properties are not really properties in the Java sense, but they serve the same purpose as properties in JSP pages. They reduce the need for the tiresome triad of a getter, setter, and member variable to code a property that corresponds to a form field. Instead, those entries are created automatically based on the request. The Struts tags, with the modifications made here, will then treat that data as properties. If initialization is required before the page is first sent to the user, you can initialize in a constructor, in the bean’s initialization block or, as in the example above, directly in the JSP. That last approach, however, mixes code and content, and it isn’t generally recommended.
Automatic properties function only within constructs that belong to Struts. Thus the getProperty and setProperty tags can’t see them. Instead, you must use JSP expressions (for getProperty) and statements (for setProperty). In particular, instead of using the setProperty tag with property="*" to map request parameters to properties by name, you call Struts’s populate function to do it.
To specify the functionality that an automatic bean must provide, let’s jot down the interface shown in Listing 2. In short, an AutoBean interface implementation must be able to associate a value with a property name. Being able to get and set objects, and not only strings, is convenient because some Struts tags require collections as attributes such as the options tag for the days in the example above.
Listing 2. AutoBean.java: The AutoBean interface
package com.bank;
public interface AutoBean {
public void set(String property, Object value);
public String get(String property);
public Object getObject(String property);
}
To make Struts work with automatic properties, you must perform some minor surgery on the BeanUtils class. The change is nondestructive in that it makes no difference for beans that don’t implement the AutoBean interface. Essentially, you implant code to get your property if the bean has no real property with the given name. Similarly, you implant your code in the populate function to use your set function when there is no real property setter for a given name. Listing 3 shows those changes:
Listing 3. BeanUtils.java: Implanting AutoBeans functionality in Struts
// new function for autobeanspublic static Object getAutoPropertyValue(Object bean, String name)
throws Exception {
if(bean instanceof com.bank.AutoBean)
return ((com.bank.AutoBean) bean).getObject(name);
throw new NoSuchMethodException("Unknown property '" + name + "'");
}
public static Object getPropertyValue(Object bean, String name)
throws Exception {
// Retrieve the property getter method for the specified property
PropertyDescriptor descriptor = getPropertyDescriptor(bean, name);
if (descriptor == null) // throw new NoSuchMethodException("Unknown property '" + name + "'"); return getAutoPropertyValue(bean, name);
...
public static void populate(Object bean, Hashtable properties)
throws Exception {
...
if (setter == null) { if(bean instanceof com.bank.AutoBean)
((com.bank.AutoBean) bean).set(name, value);
continue;
}
...
An implementation of the AutoBean interface is presented in the last section of this article. Let’s now turn to the issue of validating user input.
Validating user input with regular expressions
One of the mindless chores facing the JSP programmer is the writing and maintenance of trivial user input validation. Why not use the power of regular expressions to deal with that? And why not specify that right in the tag instead of having to write customized code around each and every input? That will eliminate the great majority of validation chores. For some tricky inputs, particularly when the validity depends on a combination of fields, you still must write validation code.
The open source Jakarta PerlUtil class makes working with regular expressions deceptively simple. The static method PerlUtil.match(pattern, string) does the trick.
By introducing attributes for a pattern and an error message at the appropriate point in the inheritance hierarchy, you endow all field tags with those attributes at once. When you are done, you can write something like this:
<struts:text
property="account"
pattern="/^[0-9]{7,9}$/"
errorMessage="requires 7 to 9 digits"/>
Somewhere in the vicinity, often right next to the field, you can place a JSP expression to show an eventual error:
<%= bean.getError("account") %>;
To nail down the functionality of validating page beans, let’s write the small interface shown in Listing 4.
Listing 4. Validator.java: The Validator interface
package com.bank;
public interface Validator {
public void setPattern(String field, String pattern);
public void setErrorMessage(String field, String message);
public String getError(String field);
public boolean validate(javax.servlet.http.HttpServletRequest request);
}
When everything is in place the setPattern and setErrorMessage methods will be called from Struts when tags using the pattern and errorMessage attributes are processed at page construction time. Those methods should simply store the association between the form field names on one hand and the patterns and the error messages on the other. The validate method will be called from the controller code after the form is submitted, and it should match the field values of the incoming request with the patterns stored earlier. If the match fails, the associated error messages should be tied to the field. The getError will be called from the JSP, and it should return that error message or an empty string if the match succeeded. Finally, the setErrorMessage method allows you to use the same mechanism to display other error messages on the page. All that is required is a call to setErrorMessage(name, message) function in the code in which the error is discovered.
Listing 5 shows the change to the Struts BaseFieldTag class that enables it to work with automatic validation. Apart from properties for the new attributes, you implant a call to give the attributes and their values to the page bean just before the page is constructed in the doStartTag method. Added code is shown in bold font.
Listing 5. BaseFieldTag.java: Implanting validator functionality in Struts
private String pattern;
public String getPattern() {
return pattern;
}
public void setPattern(String pattern) {
this.pattern = pattern;
}
private String errorMessage = null;
public String getErrorMessage() {
return errorMessage;
}
public void setErrorMessage(String errorMessage) {
this.errorMessage = errorMessage;
}
...
public int doStartTag() throws JspException { Object pagebean = pageContext.findAttribute(name);
if(pagebean instanceof com.bank.Validator) {
((com.bank.Validator) pagebean).setPattern(property, pattern);
((com.bank.Validator) pagebean).setErrorMessage(property, errorMessage);
}
...
The page bean
The PageBean shown in Listing 6 implements both the interfaces and can serve as a base class for other PageBeans. In some cases, it may even prove sufficient by itself.
The implementation of the Validator interface simply stores the given patterns and messages in maps. As a bonus, it adopts the convention of interpreting patterns and messages starting with @ as references to predefined strings. Using predefined tags can help avoid typing errors on JSP pages and help build up a repository of tested regular expression patterns. An exception should be thrown if the predefined string isn’t found, but I’ve left that out in the interest of brevity.
The validation itself predictably iterates over the fields (parameters) of the given request, locates any pattern that may have been associated with each field during the page construction (by a call to setPattern), and then calls match to compare the field value with the pattern. If the field value doesn’t match the pattern, the validation method looks up the error message for the field and stores it in the errors map with the field name as key. From there, you can access it from the JSP by calling the getError(fieldName) method.
The implementation of the AutoBean interface is even simpler. The three functions directly access a member Map to set and get the pseudoproperties.
Listing 6. PageBean.java: The base class for page beans
package com.bank;
import java.util.*;
import org.apache.oro.text.perl.*;
public class PageBean implements Validator, AutoBean {
// implementing Validator
private Perl5Util perl = new Perl5Util();
private Map patterns = new Hashtable();
private Map messages = new Hashtable();
private Map errors = new Hashtable();
private static Map namedPatterns = new Hashtable();
private static Map namedMessages = new Hashtable();
public void setPattern(String field, String pattern) {
if(pattern == null || pattern.equals(""))
return;
if(pattern.charAt(0) == '@')
pattern = (String) namedPatterns.get(pattern);
patterns.put(field, pattern);
}
public void setErrorMessage(String field, String message) {
if(message == null || message.equals(""))
return;
if(message.charAt(0) == '@')
message = (String) namedMessages.get(message);
messages.put(field, message);
public boolean validate(javax.servlet.http.HttpServletRequest request) {
errors.clear();
Enumeration e = request.getParameterNames();
while(e.hasMoreElements()) {
String field = (String) e.nextElement();
validateField(field, request.getParameter(field));
}
return errors.isEmpty();
}
private boolean validateField(String field, String value) {
String pattern = (String) patterns.get(field);
if(pattern == null)
return true;
if(perl.match(pattern, value))
return true;
errors.put(field, messages.get(field));
return false;
}
public String getError(String name) {
String result = (String) errors.get(name);
if(result == null)
return "";
return result;
}
static {
// Predefined patterns and messages
namedPatterns.put("@amount", "/^[1-9][0-9]{0,8}(,[0-9]{1,2})?$/");
namedPatterns.put("@account", "/^[0-9]{7,9}$/");
namedPatterns.put("@personName", "/^[a-zA-Z ]{0,30}$/");
namedMessages.put("@amount", "Amount can have 8 digits plus 2 decimals");
namedMessages.put("@account", "Account must have between 7 and 9 digits");
namedMessages.put("@personName", "Name can have up to 30 alphabetic characters");
}
// implementing AutoBean
private Map properties = new Hashtable();
public void set(String property, Object value) {
properties.put(property, value);
}
public String get(String property) {
return properties.get(property).toString();
}
public Object getObject(String property) {
return properties.get(property);
}
}
One small task remains to be done. You must change the tag library definition file, struts.tld, to reflect the new attributes. Listing 7 shows how you insert the new attributes into the text tag. If you want to use that with other tags, such as the password tag or the text area tags, then you must also change them.
Listing 7. Changes to struts.tld
...
<tag>
<name>text</name>
<tagclass>org.apache.struts.taglib.TextTag</tagclass><bold>
<attribute>
<name>errorMessage</name>
<required>false</required>
<rtexprvalue>true</rtexprvalue>
</attribute>
<attribute>
<name>pattern</name>
<required>false</required>
<rtexprvalue>true</rtexprvalue>
</attribute></bold>
...
Conclusion
Hopefully, the techniques presented here will help diminish the amount of robotic coding concomitant with JSP development and give you some time to deal with more challenging problems.
