(1) Module controller classs Home_C (which extends abstract class Controller) instantiates $viewmodel = new Home_M(); and displays view page so:
$this->includeView($viewmodel->Index()); //param is dbrows or only return;
So this is really M->C->V data flow, but controller does not know about model data (view knows). LINK TO CONTROLLER CLASS METHOD IN VIEW has info which model method to call, so CONTROLLER is only glue (whatever) for V and M.
(2) View page eg J:\awww\www\fwphp\glomodul4\event\eventpge_lst.php has LINK TO Event_C CONTROLLER CLASS (event), METHOD (add) :
href="<?=$module_url.QS?>event/add">Share URL (Create row).
where $module_url = $this->module_arr['module_url'] ;
(3) Read table : PAGINATED RECORD BLOCK STRING CREATED BY TABLE MODEL CLASS METHOD eg get_paginated_block() called by ... and puts it in template variable not knowing what get_paginated_block() does.
We also can use view class to call model class method, which is same thing and is "pure" M->V data flow (I tested this but do not use it). It seems to me that view class is overkill (till somebody prove oposite). View scripts are simple regarding data & code flow.
See image #2 below.
See image #2 below and MVC (MVWathever) CRUD data flow above.
This is footer text of section about. Multiple view submodules for different display environments are not needed with BootStrap - see background image.
/srv/disk16/3266814/www/phporacle.eu5.net/fwphp/glomodul/z_examples/01_PHP_bootstrap/bootstrap/inc_hdr_ftr.php, lin=34 *** ftr_pge SAYS ***INPUT: $module_arr['module_path']=/srv/disk16/3266814/www/phporacle.eu5.net/fwphp/glomodul/z_examples/01_PHP_bootstrap/bootstrap/