Re: Multiple Displays vs One Display

["Peter Dow (ML)" <maillist@xxxxxxxxxxxxxxx>]

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