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

This is far too simplistic an answer.  If business rules find a validation 
error then the information needs to travel to the user interface.  For 
real separation we can not accept a solution that requires green-screen 
involvement 

We know that our end-game involves user interfaces from many platforms and 
many methods, including green-screen, browser, Java, Windows, Linux, and 
all sorts of appliances yet to be made generally available.   Cell phones 
and Palm Pilots are not going to ever handle a 5250 data stream.

We've got to keep looking.  There's an answer somewhere.




_______________________
Booth Martin
Booth@MartinVT.com
http://www.MartinVT.com
_______________________




Douglas Handy <dhandy1@bellsouth.net>
Sent by: owner-midrange-l@midrange.com
04/10/2001 12:39 PM
Please respond to MIDRANGE-L

 
        To:     MIDRANGE-L@midrange.com
        cc: 
        Subject:        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
+---




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