Errors are more cheaply caught early, than late: that’s a well-known slogan from engineering folklore. Senior Oracle ADF Developer and frequent blogger Mahmoud ElSayed illustrates a concrete implementation of this principle in combination with the power of late binding in a recent posting he titles, “Add Validation at Runtime in ADF“.

A little background helps to understand the few words he writes there. ADF is the initialism for Application Development Framework, a Java EE (Enterprise Edition) toolkit from Oracle. ADF helps “greatly reduce the effort” of development of enterprise-class applications. ElSayed’s little example, coded in Groovy, provides a validation whose limit he determines at run-time, with a user diagnostic also assigned at run-time.

This is powerful stuff for teams that treat validation as rather a static or passive exercise: it’s immensely helpful to users to know sooner, rather than later, that values they’ve entered prevent them from moving forward. In our shop, we emphasize “intelligent user interfaces”; an important part of “intelligence” is to ask users pertinent questions. We don’t demand information that we already have, nor information we don’t need. Here’s a mundane Operations-related example: when configuring a dashboard display, we don’t offer nodes that a particular operator is blocked from seeing because of a security rule. To do so would only add confusion and frustration.

As straightforward as this might seem, it’s worth a few explicit words, because so many programmers seem to regard validation operations in a static way. If ElSayed had taken another minute, he could have further strengthened his example by factoring out the redundancy between his validation condition, and its diagnostic: while it’s important that the latter mention in human-readable words the condition violated, he missed a chance to make the salary limit a variable, rather than a duplicated literal constant.

HTML5, too

It’s a particularly apt time to think about improving validation of user entries because HTML5 gives so much in this regard. HTML5 is a rather bulky standard, with many loosely-related parts; one important area of improvement is in forms management. Think, for a moment, about the Web equivalent of ElSayed’s example of entry of an employee salary. Before HTML5, the most natural way to code this in a Web application would be with a simple <input type = "text" ... widget. It was often tempting to leave all validation to the server. HTML5, in contrast, declares a wealth of new types, including <input type = "range" ..., so that users see a standardized, well-defined numeric entry limited between a minimum and maximum. With a little JavaScript, the validation can even be adjusted dynamically, purely during the client’s run-time. This makes programming for the Web a far richer experience than it once was!

The validation that HTML5 builds in is not widely understood yet. The new pattern attribute, for instance, provides a regular-expressionfacility that few Web programmers use. The point for today is simply this, though:

• be on the lookout in your development and operations for ways to make sure data, especially user entries, are correct.
• Catch any errors as early as possible.
• Diagnose those errors in words humans understand.