Re: Data validation, mapping, and error handling

Because of this discussion and others preceding it, I'm looking at removing the drudgework of data validation, mapping, and error handling in RPG Web applications.

The first hurdle is loading meta data into memory; Record formats, field formats, field validity checks, and validity check parameters for externally defined data structures.

Given a record definition like the following, I'd like to automate the transfer between browser and record and visa versa using a single procedure call. And I think I've reached a mid-way point:

A R PETORD TEXT('PET ORDERS')
A PET 1A COLHDG('DOG?' 'CAT?' 'BIRD...')
A TEXT('PET TEXT')
A ORDERDATE L COLHDG('ORDER' 'DATE' 'MM/DD/YYYY')
A TEXT('ORDER DATE TEXT')
A COUNT 5S 0 EDTCDE(J)
A VALUES(1 2 3 4 5 1000)
A DFT(123)
A COLHDG('HOW' 'MANY' 'PETS?')
A TEXT('COUNT TEXT')
A BID 7S 2 EDTCDE(J *)
A COMP(GE 123.45)
A DFT(123.45)
A COLHDG('WHAT IS' 'YOUR' 'BID?')
A TEXT('BID AMOUNT TEXT')
A FIRSTNAME 16A CHECK(ME MF)
A DFT('DEFAULT NAME')
A VARLEN(16)
A COLHDG('WHAT IS' 'YOUR' 'NAME?')
A TEXT('FIRST NAME TEXT')

I've created a service program named RDDBRAPI that loads meta data into memory and exports a fairly simple interface for retrieving it. And I've been using it to dump meta data for any database table or SQL view to an inline frame. That's the mid-way point.

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

It's sort of like the output from the DSPFFD (Display File Field) command. Feel free to test it. You could dump the structures of files in the QSYS library, for example.

Nathan.



On Tue, Jun 10, 2008 at 2:53 PM, Joe Pluta wrote:

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
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.