Bear in mind that our base application was ported from a S/36 and is still
mostly RPG II. That said, what I usually do is write a program (RPG IV, of
course) that can serve a dual purpose: As a standalone inquiry and as a
selector for a prompt from another program.
Jerry C. Adams
IBM i Programmer/Analyst
A tree's a tree. How many more do you need to look at? - Ronald Reagan
--
A&K Wholesale
Murfreesboro, TN
615-867-5070
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Kurt Anderson
Sent: Monday, April 16, 2012 4:36 PM
To: RPG programming on the IBM i / System i
Subject: RE: Prompt Service Program.
Michael,
I may be reading a bit into your request, but are you in a situation where
you go through the pain of having to redevelop (or copy) prompt windows from
program to program to program. If there is little variation in the layout
of the display, it sounds like a good reason to create service program
procedure. However, it needs to be done in such a way to not embed business
logic into it (as noted by others).
In my original suggestion, I said you could do this with a table. Another
option is to pass in a procedure pointer.
storeSelection = displayPrompt( %pAddr( promptStore ) ); statusSelection =
displayPrompt( %pAddr( promptStatus ) );
That way your business logic for what information to display is not within
the displayPrompt procedure.
-Kurt
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Scott Klement
Sent: Monday, April 16, 2012 3:45 PM
To: RPG programming on the IBM i / System i
Subject: Re: Prompt Service Program.
Hi Michael,
On 4/16/2012 3:08 PM, Michael Schutte wrote:
/free
store = StorePrompt();
status = StatusPrompt();
/end-free
Both prompts would display a list in a window.
In my opinion, this isn't a good design.
a) The procedures StorePrompt and StatusPrompt do two things: (1) they
perform the business/database logic needed to get a list of potential values
for a field and (2) they perform the UI logic to load, display and read the
results of a screen/window.
In my opinion, a subprocedure should serve one purpose so this should be
divided into two procedures.
b) What if you needed a list of (for example) valid stores for some other
purpose besides an F4=Prompt screen? With your design, you'd have to
re-code the logic to retrieve the values. If the business rules ever
change, now you have two (or more) places to re-code the logic. (This is
strongly related to reason "a", above)
c) What if you wanted to use a different UI besides green screen?! Since
your business logic and display logic are intermixed, you'd have to rewrite
the logic.
d) Mixing completely unrelated business logic together in the same service
program will definitely become awkward. You will have the potential
(depending on how you design the file access) for hundreds of files to be
opened when you only needed one.
e) Mixing so many unrelated functions together also makes maintenance more
difficult. This object has to be re-tested and re-promoted each time you
change any of the internal "prompt procedures." With hundreds of them
included, this might mean that this service program is replaced frequently
for completely unrelated purposes. This makes it likely that two
programmers will need to make changes at the same time to the same srvpgm.
f) It doesn't make any sense to me that these are grouped together purely
because they're both invoked by "F4=Prompt"? Is the fact that they both
prompt for information REALLY the defining characteristic of each? Example:
you have a procedure described as "choosing a store number" -- what's the
most important part of that description? Is it "choosing"? Or "store
number"? I'd definitely say the latter. But, you seem to think the fact
that the user is choosing something is the defining characteristic... and I
can't agree with that. When you finally graduate into a modern display
paradigm, are you going to have a ListBox service program with all list box
procedures, and a RadioButton service program will all procedures that use
that, and a SpinButton service program will all procedures that use spin
buttons? Seems to me it's more important to group by business function
rather than the type of UI panel you are using.
In my opinion, this isn't a good design.
--
This is the RPG programming on the IBM i / System i (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 is the RPG programming on the IBM i / System i (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.
midrange.com
