Re: Data validation, mapping, and error handling

Joe,

Thanks for your reply. It impressed me that you put together a comparable example in a short amount of time.

I gather from your code sample that record validation and mapping occur automatically outside your JSFHandler. When I initiated this thread, I suspected that might be the case, and agree that it raises the bar to have the record filled in automatically by the framework. What would it take to add a validation to the date field, where a valid value is say a 3 month range from the order date?

Nathan.




----- Original Message ----
From: Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>
To: Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
Sent: Monday, June 9, 2008 10:01:37 AM
Subject: Re: [WEB400] 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