• Subject: Re: Externalize DB/IO (was What Counts as Technically Slick?)
  • From: "Leif Svalgaard" <leif@xxxxxxxx>
  • Date: Tue, 10 Apr 2001 14:06:29 -0500


----- Original Message -----
From: John Taylor <john.taylor@telusplanet.net>
To: <MIDRANGE-L@midrange.com>
Sent: Tuesday, April 10, 2001 1:34 PM
Subject: 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
> 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
> 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.

| 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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].