Re: Data validation, mapping, and error handling

Peter Dow (ML) wrote:

What I'm talking about is how it looks to the user. The user doesn't care where you put the edits; most of them wouldn't understand if you tried to explain where they are. What the user sees is what counts. In the case of the VALUES keyword in DDS, when the user enters a value outside the listed VALUES, the keyboard locks, a cryptic message is displayed saying they've entered an invalid value. A typical business rule error message is probably more descriptive of the problem, and may or may not lock the keyboard, highlight the field, position the cursor, or whatever; in other words, it acts differently.

Well, cryptic is in the eye of the beholder. I'd use "generic" as a more descriptive term, and for things like invalid date formats and required fields, it's pretty straightforward. For ranges, it's a matter of showing the user what the valid range is, which should be done anyway in a good design.

I agree entirely on the lock the keyboard stuff. I prefer seeing all errors at once, with all the fields in error highlighted and the error text next to the field. Currently you can easily do the latter and on the client-side validation you can do the former using an error style class. I've presented a Request for Enhancment to support an error style on the server side as well.

There are other options, such as a list of errors at the top or bottom and as you cursor over them, the field in error highlights. Click on the error to be taken to the field. This can actually be accomplished with EGL, along with the field highlighting above, by adding some JavaScript and then adding some attributes to the fields.

And of course, many errors such as dates and values can be avoided entirely through the use of interactive widgets such as date pickers and dropdown boxes. And then there are issues of i18n and even a11y (internationalization and accessibility). So the problem gets complex. The point, though, is that sometimes the perfect is the enemy of the good, and if you can get half of your applications knocked out with 80% of the user features you would like in 20% of the time, it may be worth it. I mean seriously, does the cost bucket category maintenance program have to be perfect?

However, business rules definitely require specific error message capability, especially for front-line OLTP programs such as order entry. And the more you extend those programs to the outside user, the more they need to be bulletproof, intuitive and good looking. There I might say it's worth the extra effort to implement a single error interface that requires manual editing for each condition.

But that would be a business decision made on a case by case basis.

Which led to the question about how EGL's field-related validation actually displays the error to the user. Is it predetermined by EGL? Do you have to define how it shows the errors? Do you (you, Joe, in this case) make your business rule errors show the errors the same way EGL does?

It's hard to explain the "how" if you don't take the tutorials (or at least take a peek at the Powerpoint that goes with them). But in general, there is a tag called h:message that has a "for" attribute. You specify the ID of the input field whose message you're interested in, and any error message will appear in that tag. You can then place that tag wherever you want, although typically you would place it either next to the widget itself or perhaps in a separate column in the table the widget appears. the point being that you can indeed place the widget wherever you want and control its appearance through standard CSS techniques.

Joe