[Info-vax] User Interface Design, Implementation

[Arne Vajhøj]

On 6/6/2019 12:00 PM, Stephen Hoffman wrote:
> 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.

Theoretical not.

But I am not aware of any common MVC framework that is not.

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

Having a display is not sufficient to being a View.

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

The database is not the model - unless you have put all your business
logic in stored procedures.

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

That is not MVC. MVC is a triangle.

It could be MVVM or MVP.

:-)

> That seems... much like what more than a few longstanding and 
> timesharing-style OpenVMS server apps do.

Not sure that I would agree on that.

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

In some ways you can consider it a remote view.

But it is typical not called MVC.

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

Which I don't get.

This is all in application code not in the OS.

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

To me what you are describing sounds more like a split of the server
side in 3 layers:
* service layer
* business logic layer
* data access layer

(maybe - you did not really go into the BLL DAL split, but that is
sort of standard)

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

I may not disagree so much with the actual approach.

But I disagree with terminology used to describe it.

Arne