Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com

Strut your stuff with JSP tags

Use and extend the open source Struts JSP tag library

By Thor Kristmundsson, JavaWorld.com, 12/01/00

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:

Figure 1. Webpage using both automatic properties and validation with regular expressions (40 KB)



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

1 | 2 | 3 |  Next >
Resources