Re: A design philosophy question -- RPG400-L

--
--
[ Picked text/plain from multipart/alternative ]
Joe, since you said a "design question" I'll take a wild potshot at your
choices.

My reaction is that your design question is the wrong question to begin with
  When we did the old-style monolithic programs they were huge amorphous
blobs that were a bear to define and understand.  Next we went to
sub-routines and then called programs, but all of these designs were tightly
integrated in a vertical way all the way from the user's fingertips to the
actual database field.  We did verifications, display designs, the whole
thing.  That was a great relief from what we'd been doing.

Then along comes the web and xml and client-server and java and all the
choices.  Vertical integration has not worked well in that arena.  People
are beginning to slice the cabbage horizontally instead of vertically.  My
experience so far is "Voila! something that is right for the times!"

Given those comments, my first reaction is that you've asked the wrong
question.  You have no real desire to design a complex multi-panel display.
You want to design the layer below the user interface.  Once that is done,
your task becomes entirely different, and you begin thinking "Which
interfaces do I wish to layer on top?  (Greenscreen, yes): (HTML, maybe);
(client server, probably); (Java, yes).

The horizontal layers I think of at first blush are:
Top: GUI interface, only. No data files touched.
3rd: business rules, validations, security
2nd: database relations, cascading deletes, trigger programs, and actual
contact with the data.
1st: data. Just the data. Untouched by any program excepting layer 2
programs.  Not even for inquiry.




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

-------Original Message-------

From: rpg400-l@midrange.com
Date: Sunday, September 29, 2002 12:33:28 PM
To: rpg400-l@midrange.com
Subject: A design philosophy question

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

_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

.
--
[ Content of type image/gif deleted ]
--