Re: Data validation, mapping, and error handling

Nathan Andelin wrote:

If you have a bunch of "required" fields on a form, but the user submits an empty form, I think it's appropriate for the form to light up like a Christmas tree (highlight empty fields), and remind the user that the form must be filled out. I use a standard JavaScript function for that.

Agreed. In EGL, you simply define InputRequired=yes for the field. Similarly with most of the basic validations.

You made a very good point in an earlier post that "records" are a central construct in all business applications. If you define "records" with meta language and have the framework automatically map HTML input elements to records, that's a good thing. But the framework shouldn't map "Hi Bill!" to a numeric data type. It should generate an error.

Agreed again. And while this particular error could probably be handled by the browser as well, the point is still that some errors will bubble up to the server but not quite to the business logic. These are "controller" errors in Aaron's terms, and are probably median-level errors such as ranges and valid values (although many of those could be moved to the client as well).

Finally, I think it's clearly understood that all applications will have unique validation rules that need to be handled by custom code.

Of course. My guess is that most of those will be handled in the business logic, though. Anything that, for example, requires database access should most likely be in a server. But again the exact placement of each error doesn't invalidate the idea that there are "error tiers", if you will.

However, it would be good if 1,2,3 all used the same error mechanism, for consistency purposes.

If by error mechanism you mean the visual cues and user interaction that occurs for each, then I agree. I don't think they necessarily have to be done in the same piece of code; to me, if you can inherit many of the simple edits from the application's metadata while still maintaining a consistent look and feel, then it's a no-brainer. Less programming, less chance for error, everybody wins.

It's even possible that you might have two distinct look-and-feels: one for simpler screens that aren't used often and are primarily utility types of applications, and one for "power applications" where the end user experience outweighs the benefits of being able to automate some of the rules.

But you know what I'm going to say, right? It should be ... a business decision <smile>.

Joe