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

I'm still pondering the ideas voiced by John Taylor, Brad Stone, and Leif S.
But to answer Douglas Handy's post, I'll submit this response:

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

>I'd rather just send them as messages to the external program
>message queue of the UI program.  That is one of the beauties
>of the error message subfile.

Good suggestion.

>And herein lies the rub, as you are losing some of the separation
>you are striving to obtain.  Just how do you propose this array
>of indicators gets mapped to the fields?  I'm not saying it can't
>be done; I just want to see how you suggest doing it in a real
>life setting.  In fact, that is my real motive for responding.  I
>*want* to see how others handle this when separating the UI
>from the business logic and DB I/O.

D dbFlags S 1A Dim(20) Import

C If Not dbAdd()
C  Movea dbFlags *In50
C  LeaveSr
C EndIf

In this example, Indicators 50 - 69 are reserved for display file field
attributes (cursor position/highlight).  The dbAdd() procedure sets
corresponding values in the dbFlags array during the validation logic.  The
screen I/O module then moves the dbFlags array to the *IN array, to set the
"real" indicator values.

>Actually, I don't even use indicators anymore.  I prefer to use
>program-to-system fields to set display attributes, and set the
>cursor location by dynamically retrieving the DSPF format's
>field locations via APIs at runtime.  All of that is encapsulated
>behind service program routines which make it a single sub-
>procedure call for me to add a message to the subfile, set the
>display attributes, and position the cursor (if it is the first error).
>No indicators involved.

This is over my head.  Care to elaborate?

>Don't get me wrong.  I'm a big fan of service programs and
>subprocedures in general.  At the time I played with externalizing
>the DB access, the concept of using web-facing or whatever
>technology as an alternative UI was not part of the equation.

Yea.  The prospect of servicing multiple Web clients was the thing that
finally got me looking at externalizing DB I/O.

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