Re: Data validation, mapping, and error handling

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

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