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