RE: Multiple Displays vs One Display -- RPG400-L

Scott,

Honestly, I would have sworn you were one of the experts recommending it...guess not <grin>

Don't have any links off the top of my head, but IIRC I've seen articles in both MC Press and System i
News.

Consider a customer maint program, the first screen is probably some sort of Work with type screen.

From that you can probably Add/Change a particular customer plus maintain lots of other "customer"

related info like customer pricing.

Assuming monolithic programming, all that functionality is in one program and all the screens are in
the one display file used by that program. I know you'd agree this is bad.

So you break stuff apart, the Work with screen is in one program, the add/change screen(s) is another,
the customer pricing yet another.
This is of course a good thing.

So what happens when for instance, all the data needed to add a customer doesn't fit on one physical
screen. I think historically, RPG programmers had all the screens for the add customer function in a
single display file driven by a single program. However, I think that splitting each screen into it's
own program/module is not a bad thing. You can then call them wrap the calls in an "Add Customer
Wizard".

From an MVC standpoint, the DB is still the model, the individual programs/modules make up the view,

and the Add customer wizard becomes the controller.

All we're really talking about is breaking down the functionality into multiple self contained pieces.

From a maintenance and reusability stand point, I think that's a good thing.

As a side note, here at my (relatively) new job. We use CA's Plex ARAD tool to generate our RPG 5250
apps. In Plex, a UI function can contain only one screen and generates as a single RPG program.

Charles

-----Original Message-----
From: rpg400-l-bounces+wiltc=cintas.com@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+wiltc=cintas.com@xxxxxxxxxxxx] On
Behalf Of Scott Klement
Sent: Wednesday, October 31, 2007 2:19 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Multiple Displays vs One Display

This is an interesting thread. I've never hard of this "one
screen / one module" recommendation before. I'm having a
hard time understanding why you'd do this...

All of the recommendations I've seen involve separating the
display logic from the business logic -- usually using an MVC
pattern. I've never heard of separating the display logic
from other display logic. I don't understand the advantages
of separating each screen from the other ones.

Can you please provide links to where you saw these recommendations?
Preferably, a link to an article that really explains the
premise of this technique?

Thanks

Wilt, Charles wrote:

Now-a-days, I think most the experts recommend one screen per
module/program. While not an expert, that's what I'd recommend also
:)

Tends to lead to more modular programming. Maintenance is

easier as

you don't have to worry about accidentally changing another screens
behavior.

Also makes it easy to call a particular screen from someplace else.

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

This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.