Data validation, mapping, and error handling

[Nathan Andelin <nandelin@xxxxxxxxx>]

Last week, Pete Helgren posted a blog entry on the EGL-I List that implied that EGL addressed two of the greatest obstacles that RPG developers face in adopting Web technologies.  Paraphrasing the noted obstacles:

1.    Learning browser lingo (HTML, CSS, JavaScript, DOM).
2.   Data validation, mapping (between form and database fields), and error handling.

When two or more developers begin saying the same thing (Pete Helgren. and Joe Pluta, in this case) it makes me take note; maybe we can learn something about how EGL works.

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.

I use a set of generic procedures to retrieve HTML input values, validate them, and convert them to appropriate data types, including validation and conversion procedures for integer, date, time, real, monetary, string, and so forth.  To illustrate, I put together a simplistic order entry form which also includes a link to the RPG source:

http://www.radile.com/rdweb/temp/pets.html

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).

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.

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.

Nathan.