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

Nathan,

>To implement multi-field validation, I'd need a broader interface between
>the two modules.  

My point exactly.  The sample program was too simplistic to be a real wrold
example, which makes it useless for comparison purposes (IMHO).

>The dbMsg field
>could have been a multiple occurring data structure to hold the maximum
>number of error messages possible.  

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.

>It could be supplemented with an array
>of indicators to highlight multiple fields on the screen.

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.

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 run
time.  All of that is encapsulated behind service program routines which make it
a single subprocedure 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.  

I may be able to extend this logic and with proper naming conventions, accept DB
field names back from the business logic handler then make my other WS handling
routines deal with it.

I just wanted to know how you handle it, since it appeared to have been
production code rather than something thrown together for the posting.

>Only after testing the concept, and after doing
>some "reuse by copy" for another application, did it grow on me.

Years ago I tried setting up service programs to encapsulate the I/O to some
commonly used master files.  This was on a CISC system, and before the RPG IV
redbook.  I got it to work.  When it was all said and done, it didn't seem like
it had bought me any real, tangible benefits.  Perhaps I just did it wrong.

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. 

This alters the balance somewhat, and I can see where externalizing the I/O is
good positioning.  What I need though are solid examples of how best to
integrate that with existing UIs without going backwards (e.g. losing cursor
positioning or field highlighting) while keeping it at least as maintainable --
and preferably better.

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