[Info-vax] User Interface Design, Implementation

[Stephen Hoffman]

On 2019-06-06 14:11:28 +0000, Arne Vajhj said:

> MVC is a pattern used by some GUI frameworks.
> 
> Non-GUI applications does not use MVC.
> 
> GUI applications using a non-MVC framework does not use MVC.

Are you positing that an MVC-style app design requires graphics?

Because it really doesn't.

Sure, some MVC frameworks are built for graphics interfaces, or for a 
web interface.  But I'm referencing the internal segmentation of the 
app code.

Okay.  Given the sort of large and longstanding timesharing apps that 
more than a few OpenVMS sites have built and still have...

...We have a view.  A display of some sort.  Often a character cell 
device using ANSI controls.  Or a command-line interface.

And... we have a model.  A database or three.  Either locally, or some 
other data accessed remotely.

And... we can have a controller.  A blob of code that among other 
tasks, mediates the chatter between the view and the model.

That seems... much like what more than a few longstanding and 
timesharing-style OpenVMS server apps do.  Though many of these 
long-existing apps don't split off the pieces.  Which can be part of 
why folks are still display character cell interfaces and terminal 
emulators for some apps.

What's the difference between an ANSI control sequence or command-line 
interface, and a network interface that passes along a different sort 
of data either for a remote user or for a remote server, whether for 
use by a dedicated client app either in a browser, or a standalone app 
on another computer?  Or by another server?  In terms of what has to 
happen in the app code, not all that much.  Sure, different APIs.  But 
there are different APIs for different GUI interfaces, too.

And as I've mentioned, some of the refactoring that works well when 
updating and upgrading OpenVMS apps is retrofitting something akin to 
MVC, and particularly splitting off the code related to what MVC calls 
the View.

Variously with each of the device-specific views into 
dynamically-activated shareable images on OpenVMS, as that can avoid 
problems at image activation time when some other dependency might be 
missing in a particular environment.   In older configurations, the 
DECwindows and VWS/UIS shareable images weren't always installed 
everywhere, for instance.  In a more recent era, it can be around 
activating different TLS shareable images that may or may not be 
present.   Or for whether OpenGL is installed, for that matter.

The views can be for providing data to LAT printers, and more recently 
data for IP printers via telnet or lpr/lpd, or then via IPP if/when.  
And again, I don't see the app code to manage a remote network 
connection to some other app—and that remote app or remote server may 
well not be doing MVC-style designs within, or it might be—as being 
particularly different from the app code needed code to manage a local 
or an X GUI display, or different sorts of printer connections, or for 
different network transports.

This also all gets back to the piles of code needed to do some of these 
functions, whether it's the often-existing piles of code needed for 
character cell, whether home-grown or SMG or FMS calls, or otherwise.  
And for various folks, the lack of piles of code and/or frameworks to 
do different views within the available staff and the available budget. 
 Such as (the lack of) frameworks for REST or whatever, for a view that 
might be providing a data service for a remote GUI client app.

Does everybody consider a network connection a view in an MVC pattern?  
Of course not.  But it's really quite similar, interfacing what amounts 
to a controller with a different display client.  And it's an approach 
that works well with updating the piles of bespoke code that exists at 
many OpenVMS sites.  Implementation details and languages and 
requirements can and do vary.  A pile of BASIC or C++ or C or Fortran 
can still be designed to segment the various areas, akin to what MVC 
and such posit.

Your approach and your opinion around MVC is one you're fully entitled 
to, of course.  I just think you're really missing out on an approach 
that works well for refactoring existing OpenVMS code.



-- 
Pure Personal Opinion | HoffmanLabs LLC