Re: Data validation, mapping, and error handling -- WEB400

Maurice,

I appreciate your feedback, but I don't see much point in auto-generating JavaScript validation routines, even though Microsoft may do that. I'll just stick with validation on the server. I don't see much point in complicating the interface.

Nathan.

----- Original Message ----
From: Maurice O'Prey <maurice.oprey@xxxxxxxxx>
To: Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
Sent: Wednesday, June 18, 2008 1:48:30 PM
Subject: Re: [WEB400] Data validation, mapping, and error handling

Hi Nathan

It would seem to me that your next step is to write some server side code
(in RPG) that that detects the browser (and version) in use and auto
generates the correct client side JavaScript to handle the validation for
whatever validation rules you define, then you will obviously want some sort
of code to validate the post back server side (should anyone remove the
JavaScript).

Good luck with this endeavour (it would be easier IMHO to use ASP.NET since
this already does this?)

Regards

Maurice O'Prey

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.