Here at my company our business is all about forms. I’m not talking about HTML forms; I’m talking about business forms such as loan applications, tax reporting statements, etc.

We’ve got quite a collection of applications that deal with our forms, and we’ve implemented them in everything from COBOL to Java. We’ve got desktop based applications, browser based applications, mainframe batch processes, stored procedures and web services. The one business requirement that is common among these applications is this; the rules that govern what constitutes valid input for a specific form must always be the same.

This is by no means a unique situation. For example, the rules governing an IRS Form 10-40ez don’t change just because you’re using the web-based Turbo Tax rather then the desktop edition (If they did, Intuit would be in a world of trouble).

Given that all of the forms that my company deals with are well defined (and heavily regulated), one can easily envision a common repository of knowledge from which all of our applications programmatically draw the information necessary to validate field values. If the definition of one of our forms is amended (perhaps due to a regulatory change) the change will be picked up by all of our applications to insure consistent form processing across our enterprise.

Sadly, we have no such facility. We have a substantial knowledge base regarding our business, both in terms of human resources and extensive documentation, but we do not have a machine parse-able equivalent. When the definition of a form changes, we have to go through all of our systems and manually update them, and a considerable effort is expended to make sure that everything stays consistent.

This issue is one of my pet peeves, and I’m not alone. A few months back there was a good discussion on this subject on the Java Server Faces forum, and much of this blog owes thanks to the folks who chimed in at that time.

I am concerned that we Java folks are missing the boat in not generally recognizing the linkage between field validation and the underlying business forms. To illustrate my point, consider how field validation will be handled in Java Server Faces.

JSF encourages separation of concerns. Architects are encouraged to compartmentalize the design into Model, View (Presentation), and Controller concerns, and authors can be assigned to each layer. This is great.

What’s not so great (in my view) is that the current design of the JSF validation tags assigns the responsibility for defining field validations to the page author. To validate a field value, the pages author “registers the validator on a component by nesting the validator's tag within the component's tag" (excerpt from the JSF tutorial).

This bothers me because it requires the page author to have knowledge about a field’s meaning in order to select the correct validation tag.

I am not concerned that field validation is performed in the presentation layer. Validation should generally occur as close to the user as possible to provide the best possible feedback when an error is detected. I am concerned that validation is defined in the presentation layer.

Elsewhere in the JSF tutorial the responsibility for designing forms is assigned to the model author (as it should be). The form designer defines all of the fields that make up the form bean, and most likely has the knowledge of what values are acceptable for each field.

Consider the process of developing and maintaining an application: How will the rules that govern a form’s fields be conveyed from the form designer (model author) to the page designer (presentation author)? Unless this process is mechanical, it will be prone to error.

Perhaps we need a convention for specifying validation rules within form bean definitions... We now have the Java Bean getXXX and setXXX for dealing with the value of property XXX; perhaps we need "getContraintsXXX".

With such a convention, we could develop JSF validation tags to extract rules from the model, rather then having to communicate the rules to the page authors and running the risk of introducing errors. In addition, if the rules that govern a form’s fields reside with the form definition it will be easier to insure that all of the views remain consistent (even views that are web services rather then HTML).

Note that this solution only partially addresses my base concern since it deals with the HTML forms passed to the user rather then the underlying business forms, but it's a start.

Philosophically, the Struts Validator is closer to my preferred approach. With the Struts Validator, form validations for a specific application are specified in a single file named validator.xml. Unfortunately (from my perspective) the rules are defined separately from the target form, and from a packaging perspective I have not figured out how to bind the rules to every application that uses a specific form.

Another approach that I find interesting is the XForms model for constraining values. With XForms, rich declarative validation information can be included in each form definition. For a company like ours, I can envision creating detailed XForms definitions for all of our business forms, and letting those drive validation throughout the process.

Here is a summary of my thoughts:

• Field validation of business forms is an important concern of many applications
• The business owners should specify the field validation rules - this is business logic, not presentation logic
• The validation rules associated with fields should be specified as part of the model – the rules are tied to the meaning of the data, and the meaning should remain the same regardless of the presentation
• There may be presentation specific rules that are associated with a specific implementation, but the model’s rules should not be violated - the model's rules should percolate up to the presentation layers
• We need a standard for specifying field constraints within form definitions, and for accessing those definitions - XML web services standards and XForms might provide good starting points

Update: See my later blog on JSF and Field Validation

Update: 11Mar05 - Check out Anders Holmgren's Using Java Annotations to add Validity Constraints to Java Bean Properties.