Re: Data validation, mapping, and error handling

Nathan Andelin wrote:

Regarding the second problem, I grant that there's something of a disconnect between HTML input elements and fields in database tables. HTML input elements are always passed to the HTTP server as character strings, while database fields may be various types (date, time, time-stamp, packed, zoned numeric, boolean, etc.), so fields obviously must be validated and converted to appropriate types as they move from browser to database and visa versa.

And this is exactly what EGL removes.

Try entering incomplete or invalid data. Look at the RPG source. See that each HTML input element requires a block of code to handle it (retrieval, type validation and conversion, mapping to a subfield in a data structure, and error handling).

Note that in my example, all the fields are edited at once, all the messages are shown. My only downfall right now is that I haven't figured the easy way to "reverse image" the input field when it's in error. I'm certain there is a way, but if there isn't we need a way to add that. It should be as easy as checking for an error and applying a different style if there is one.

But short of that, my page does what yours does, and maybe even a little better.

In my toolkit, type validation and conversion procedures have a name prefix of "cki" which is an acronym for "check input", and a name suffix corresponding with the type of data input (integer, date, & so forth). All procedures return a boolean value indicating success or fail, and fill in an export data structure with a converted value [or] error message. Numeric and date procedures can optionally validate a range of values.

With EGL, validation is at the data item level, not the program level. What happens is that you define the validation when you define the field. This can be at a field reference level, at a record level, or even at the program level if you need special validation for a specific program. But the point is that once you define the validation, you don't write any code.

It would be ideal if someone would post a comparable example using EGL, so we could see how it addresses this issue. Has EGL raised the bar? Is the interface more seamless? I'd appreciate your feedback.

Sure... take a look here:

http://rsdc.plutabrothers.com:9081/GettinWebbie/Editing.faces

The page even shows the entire EGL source. Take a look at the source. How much more seamless can you get? The fields are represented by the record "bid", which is defined at the bottom of the source. This happens tobe an ad hoc record, but could also be a record from a database if you were so inclined.

By the way, the validation is defined in the record in this case:

record Bid type BasicRecord
wanted date ;
quantity decimal(4,0) { ValidValues = [[1, 1000]] };
bidprice money (6,2) { ValidValues = [[1.00, 1000.00]] };
name string { InputRequired = yes };
end

This is server-side validation. It can get much more complex, using data tables and even custom code, but I wanted to show you just how seamless EGL really is. There is also a complete set of client-side validation, based primarily on regular expressions, which can be applied as you exit individual fields. That does have the ability to change the class of the input field, but I'm not an expert yet.

Joe