Jsp struts 1.2
Keywords: jsp struts 1.2
Description: Learn how to use the custom tags from the open source Struts library and create extensions that ease the coding of properties associated with field values and user input validation.
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.
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.
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
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.
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.
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:
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.
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:
Somewhere in the vicinity, often right next to the field, you can place a JSP expression to show an eventual error:
To nail down the functionality of validating page beans, let's write the small interface shown in Listing 4.
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.