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

["Nathan M. Andelin" <nathanma@xxxxxxxxx>]

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

>Nathan,

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

>I figured it was something like that.  But this has more of a direct link
>between the business logic and the UI than I'd like in terms of having to
know
>ordering etc.


Good point.  If you simply pass an array of indicators between client and
server, there must be an "understood" mapping of array element and
corresponding field.  This might be fine if you're the only programmer.  But
for the server to be used by others, you might want something more explicit.
Perhaps the interface should be a multiple occuring "error" structure, with
subfields of  field-name and error-text.  The UI program would need to add
logic to map rows in the structure to field attributes in the screen file.


>John's solution is great from a capability standpoint, and let's
>the business rules program be truly indpendent from any UI
>considerations.  This is ideal. But does the UI program really
>end up looking simpler by the time you are done?
>Maybe it does by the time you make routines to work with
>the attribute structures.


<snip from John Taylor>

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

<end snip>

I don't think I get the full meaning of John Taylor's suggestion.  The
AttributeValue property implies that this structure might be used by field
"getter" and "setter" methods, and other I/O methods popularized by OO
languages, as well as for error management.  If so, whouldn't that negate
the simplicity of OS/400 record level 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
+---