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

My .02

Don't rely upon direct parameter passing, or module import/export variables
between the client and the DB server. Encapsulate the parameters in a data
structure that can be passed as a single parameter, or shuttled across via
data queues, user spaces etc.

To begin with, you need to establish a common naming system for all data
attributes within your system. So you'd have attributes like:

Product_ID
Product_Desc
Product_Status

The server and all clients must use this naming system to refer to the
attributes - no exceptions.

Next, setup a standard data structure that will encapsulate each attribute
in a common way. Think of this data structure as a composite variable - the
API Error Structure is similar to what I'm talking about. Example:

AttributeStruct:
  AttributeID="Product_Code"
  AttributeValue="ABC123"
  AttributeSeq="1"
  AttributeErrID=""
  AttributeErrText=""

The client is responsible for setting the attribute sequence value before
passing the attribute to the server. If the server encounters an error, it
sets the AttributeErrID and associated text accordingly. In this model,
where each attribute structure provides a vehicle for it's own message
passing, the server would ignore the AttributeSeq value - it would only be
used by the client.

However, another valid model would be to take the message passing out of
each individual attribute, and add it as a standard attribute itself. In
that case, the server would generate and pass all error messages as a single
attribute that contained deliminated error messages. As part of this
packaging process, the server would use the AttributeSeq value to determine
what order the error messages should be placed in.

The attribute sequence, of course, has a direct relationship to the order of
fields on the display file, HTML page etc. The client uses the value to
arrange the error messages and for cursor control.

If you want to be really hip about it, package this all up using XML.


Regards,

John Taylor
Canada

----- Original Message -----
From: "Douglas Handy" <dhandy1@bellsouth.net>
To: <MIDRANGE-L@midrange.com>
Sent: Tuesday, April 10, 2001 10:39
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
+---