Re: Externalize DB/IO (was What Counts as Technically Slick?)

> From: Douglas Handy <dhandy1@bellsouth.net>

> Nathan,

> >You might notice it's missing a lot of I/O
> >related error checking, data validation, etc.
>
> (snip)
>
> >But that's the sort of logic the UI control module
> >doesn't need to worry about.  Also consider how dbAdd() handles all data
> >validation without the UI control module worrying about it.
>
> To play Devil's Advocate here, let's take the example of dbAdd data
validation
> and the user interface.  Let's say dbAdd fails and returns a message in
dbMsg,
> which then propagates to wsuMsg for display.
>
> How does the UI portion highlight the field(s) related to the error
message, and
> position the cursor for the user?  With multiple errors, I expect all of
the
> fields to get highlighted, an error message subfile to have all the
message
> texts (although admittedly few users roll it), and the first field in
error to
> have the cursor positioned to it.
>
> And I further expect the message subfile to be in the order the fields
appear on
> the screen.  Or at least the very first message better be for the field
where
> the cursor got positioned (and that needs to be the top highlighted
field).
>
> How does dbAdd know which error happens to be the top field in error on
this
> particular display format so dbMsg has a reasonable text (assuming it is a
> single text string)?
>
> A trigger program or constraint can easily enforce business rules.  But
how do
> you then communicate that back to the UI layer in the manner they have
used for
> the last 20 years?
>
> IMHO, it is simply not acceptable to put the cursor back at the top of the
> screen with a generic message, or even a specific message which relates to
> something near the bottom of the screen when other errors exist higher on
the
> screen.
>
> So what do you do?
>
> Doug

Excellent question, Doug.  One that I also asked myself as I was considering
separating DB I/O from screen I/O.  The only field validation my sample
program enforced was on the file key, which must be unique.  So the
requirement you have stated were not demonstrated.

To implement multi-field validation, I'd need a broader interface between
the two modules.  And that was my primary reason for separating DB I/O into
a module, instead of a service program.  Both modules can share "global"
variables via Export and Import keywords.  The "separation purists" may not
agree, but in my opinion, it seemed like a better solution.  The dbMsg field
could have been a multiple occurring data structure to hold the maximum
number of error messages possible.  It could be supplemented with an array
of indicators to highlight multiple fields on the screen.

By using Export and Import keywords, some may argue that it's not a complete
separation, but what the heck.  I was just testing the concept and was
willing to make compromises.  I mentioned my skepticism in earlier posts.  I
played Devils Advocate.  Only after testing the concept, and after doing
some "reuse by copy" for another application, did it grow on me.

Nathan.



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---