Many things in your Web application input forms need checking. A field might be required or an entry might need to be a number only. Dates might need to be captured in a standard format. Apostrophes in text boxes and text areas might need to be escaped so that they don’t cause SQL errors.

As long as your Web application has only a few input forms, it’s possible to use hard-coded validation scripts. But if you’re working on a large application with several hundred forms, the task of providing validation for each field can become quite daunting. We’re going to show you how to create server-side components to automate validation and standardize the look and feel of all the forms of your Web application. You can download the Java code for this article here.

Component architecture
Validating on the client avoids the hassle (for the user) of server-side validation. JavaScript (cross-browser, even) is the best tool for this task. When it comes to the component architecture, you have several choices, including JavaBeans and COM components. For the purposes of this article, I have chosen JavaBeans, but you could achieve the same results with COM or XSL, for example.

JavaScript functions
The first step toward automating validation is to create a few JavaScript functions that handle common validation tasks. Listing A provides a JavaScript function that checks for zero-length strings and displays an error message if one is found. The checkNull function receives two parameters, inputname and columnlabel.

The inputname parameter contains the name of the form, as well as the name of the form element, so the full string being evaluated reads something like this:

The name of the textbox might be firstname because it corresponds with a database column of the same name. If we wanted to display the form element’s name to the user as first name, we would use columnlabel.

Using a similar method, you can also check to see whether a text element contains an integer, as shown in Listing B. If the value is not an integer, the form is not submitted, and an error message is displayed to the user.

Form components
Form components take the next step toward automatic validation. A form component includes an HTML data input, such as a textbox, a text area, or a select. We want form components to fit seamlessly with the HTML, but we also want to automate as much as possible. So what you need is a component that has an HTML display, gets data from the user, and performs its own validation.

In this scenario, a component developer would be a separate job function from a page author, who is responsible for writing the HTML, JavaScript, and Java Server Pages. The page author works alongside the developer or a component developer, who creates reusable components to be used by the page authors in their HTML.

The page author who makes use of these input components to create forms will quickly realize the usefulness and reduced coding time that the reusable form component offers. We want page authors to be able to add any HTML form components of their own and to do their own JavaScript validation.

The architecture for your form component
Several component architectures could be used to create the form components. I have chosen the JavaBeans framework, but other architectures certainly could do the trick. Our aim is to create components that automate time-consuming tasks.

Creating components adds to the instructions, or programming toolkit, that a page author has easy access to. A large component set is like a small programming language, and it is up to the system architect to determine and maintain the semantics of the language, ensuring that the language is indeed easy to use.

To keep integration with the HTML as easy as possible, the components output table rows (<tr>…</tr>). The display is contained in two table data elements, the label and the form element (for example, a textbox or a text area). Listing C shows the code for the Form component JavaBean.

The Form JavaBean can have several methods, including textbox(), textarea(), header(), submitButton(), timebox(), moneybox(), floatbox(), intbox(), and dateSelect(). Each of these methods outputs the corresponding HTML and validation. Listing D contains the code.

Note that in this example, the columnlabel is displayed in lowercase. Using form JavaBeans, it is possible to ensure that all textboxes in the application are displayed in a standard way.

The textbox method can be changed to include more functionality. For example, it can return <tr> or <td> elements, depending on the needs of the page author. Also, the HTML maxlength can be passed into the method. For text input, I like to link the maxlength value to the length of the field in the database, ensuring that the inputted text is never longer than the maximum length of the field in the database.

The validation for each component is appended to the validation String. This validation is simply appended to the end of the page being sent back to the user.

Listing E shows the validation for the textbox().

Notice that the columnname and columnlabel are used both for creating the HTML output and for the JavaScript validation. The columnname identifies the form element, and the columnlabel is used in an error message to the user.

In the form page, the HTML components are displayed first, and the validation String is built up every time one of the HTML generating methods is called. Once the form has been displayed, it will be possible to do the validation.

As each method in the JavaBean is called, JavaScript validation is added to the validation variable. This validation is specific to the form component being added, so a required textbox() might add a JavaScript call to checkNull(). The author simply inserts all of the automated validation into the script in one line:

Remember that the page author needs to be able to add custom validation. In the following example, the page author makes two form elements required, requestToID and leaveTypeID, by calling the checkNull method, as shown in Listing F.

Each of the Form JavaBean’s display methods outputs the appropriate HTML display. The validation is done in the same method, thus combining form element display with form validation.

The result is a simple and effective way for component programmers to give page authors added programming functionality without removing the page author’s ability to add custom HTML and validation.