RE: A design philosophy question

Design:

I did something very similar to what you are suggesting, although it was not on 
an AS/400 and was not in RPG.

I found that I was having the user display or modify the same information a 
number of times, and got tired of copying/recreating the same code over an over.

So, I stuck a module in a compile time object (compile with copy) that would 
receive some parameters and would decide what to do.  Take, for instance, 
customer name and address.  This is shown or displayed quite a bit, customer 
maintenance, invoice creating, invoice lookup, etc...  This would receive 3 
optional parameters.  CustNumber, Modify, Ask.  If CustNumber was passed I 
would chain to the record first.  If Modify was on, I would display the fields 
for editing, other wise for display.  If Ask was on I would have this module 
prompt the user for the customer number to edit/display.

It worked out very well for me, and I found that I could then very quickly with 
one line of code call up the customer information screen for whatever I wanted 
to do, and threw it in a lot of places I normally wouldn't of before.  And, my 
software then had the advantage that no matter where in the system they were 
looking/modifying the customer information it always looked the same.  If I 
added or changed a field, I did it in one place and was done with it.

Mine was more like your 3rd or 4th choice.  The customer maintained program 
itself then became very short.  A few lines of code actually.  And then by 
adding 1 or 2 lines to the invoice program they could look at the customer 
detail if they put a ? in the field (or maybe it was F4 or something, it's been 
a while).

You might have fun, however, figuring out how to get the record buffer from 
your program into/out of a module without having to pass the entire buffer.

Regards,

Jim Langston

-----Original Message-----
From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]

How would you design a complex multi-panel display?

Let's take, for example, an order entry display.  There's a screen for the
ship-to information, a screen for notes, a screen for order header
information, a screen for order detail, a screen for shipment detail.

It seems to me there are a number of possibilities:

1. One really big display file handles by one really big program
2. Separate programs, each with its own display file, run by a driver
program
3. Separate modules, each with its own display file, called using bound
calls from a driver program
4. Separate modules, each with its own display file, in a service program,
called from a driver program

Option one is bad, for all the reasons we've come to know and hate over the
years - maintenance, modularity, and so on.  So that leaves the other
options.  What are the opros and cons of having a display file in a module?
And what are the tradeoffs between having such a module bound or in a
service program?

I'm not looking for a definitive "right" answer here; my guess is that "it
depends".  But I'd like to have a little discussion on the matter.  I guess
that's becase I'm at option two today, and very comfortable with it, but I
know that I'd get at least one benefit from a bound approach: fewer objects
to manage, especially in the production environment.  That goes away a
little if I move to a service program approach, but then maintenance is a
bit easier.

So, please, I'd be interested to hear what you think.  Any comments about AG
usage in this scenario would be appreciated as well.

Joe