Re: Multiple Displays vs One Display

[Jerry Adams <jerry@xxxxxxxxxxxxxxx>]

Yeah, CCP was a pain in the butt, wasn't it, Peter?  I almost went into 
construction when it came out.

	* Jerry C. Adams
*IBM System i Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
	615.995.7024
fax
	615.995.1201
email
	jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>



Peter Dow (ML) wrote:
> Hi Scott,
>
> Way back when I first started working on the Sys3 Mod15D they had CCP (I 
> think it was Communications Control Program), and there were two 
> recommendations - SRT and MRT programs.  The idea SRT (Single Requesting 
> Terminal?)  was for the program to quickly display a screen that 
> contained the name of the next  program that would process that screen 
> embedded as a hidden field.  When the user pressed Enter, the system 
> would use that hidden name to call the program and let it process the 
> screen.  This meant that while the user was filling in the screen 
> fields, there was no program taking up any of the 32KB or whatever 
> memory the machine had.  It also meant that programs were small, so that 
> when they were in memory, there was room for other programs.
>
> An MRT (Multiple Requesting Terminals?) program was designed to handle 
> several users at once.  It had to keep track of the data for each 
> requester and respond appropriately when it received a request from that 
> user's terminal.
>
> I think of the SRT model a lot when looking at browser-based programs...
>
> *Peter Dow* /
> Dow Software Services, Inc.
> 909 793-9050
> pdow@xxxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxxx> /
>
> Scott Klement wrote:
>   
> > 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.
> > >
> > >     
> > >