Re: Data validation, mapping, and error handling

So if I understand where you are going with this, you could have this meta
data associated with a HTML form field, and upon being submitted up to the
iSeries you would have it auto-validated based on the meta data?

If so, that is pretty cool! Especially if you could make it so you could
apply business logic errors AND the automated "valid data based on data
type" checking in the same round trip.

Feel free to ignore this question if you don't want to answer it, but I am
curious to know if you are going to be involved with the coming IceBreak
Open Source version? By "involved" I mean actively participating in
furthering development and acting as a guide for new features (like you have
done here with the meta data idea). You obviously have your own framework
and have found efficiencies to build apps on the i, but I would guess that
as a group we could come up with a solid solution much quicker than if we
did it separate.

Aaron Bartell
http://mowyourlawn.com

On Wed, Jun 18, 2008 at 11:50 AM, Nathan Andelin <nandelin@xxxxxxxxxxxx>
wrote:

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.

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