Re: Data validation, mapping, and error handling

Aaron Bartell wrote:

I guess this is one of those things that I would be interested to know if
people are still using the EGL out-of-the-box validation in 2 to 3 years or
adopted something that in the end saves them time long-term vs. short-term.
Time will tell...

I think there are at least three distinct categories of edits: data entry edits (numeric fields, correct date formats, and so on), reasonability checks (simple ranges, email addresses, that sort of thing) and then business logic checks.

I think it can be argued that all of the first type are best suited in the client to avoid round trips, while all of the latter must be on the host. Because of this, I think the "all editing in one place" philosophy is perhaps not as strongly indicated as it is in, say, the 5250 environment.

The biggest argument will be for the middle cases. That's doing to be purely on a case-by-case basis. I'll be honest, I'm not particularly impressed with some of the middle-layer edits, primarily because they don't seem to support using values from the backing bean. If you can't specify the contents of ranges, values and masks at runtime, the framework has considerably less flexibility than I consider necessary.

At the same time, though, being able to simply specify "InputRequired = Yes" on a field definition and have the UI take care of the editing is a nice capability. But even there I still have one major question: is there a "Command Attention" feature? That is, can you set an attribute on a command button that effectively skips all editing? Otherwise, you end up with pages where the user can't even use the Cancel button, because it never gets back to the program.

All that being said, though, I'm pretty comfortable I can create pretty powerful user interfaces using EGL/JSF quite a bit more quickly than with other techniques. My guess is that hand-coded substitution frameworks such as RPG-CGI still have an advantage on very unique interactions, but in that case, I'd have to drop back to the standard JSP approach, where I have just as much control, except that I have to sacrifice some of the ease-of-use of JSF.

Joe