You are in View:

Paths and URLs

This page URL is below Web server root path wsroot_path?> (=REQUEST_URI) : req_uri?>

This is adrs module in same named folder (Oper. System adress) :

              User (URL)

 U uses C                 1.U sees V

 Controller  controls V   View

 3.C manipulates M         2.M updates V


Principle of M-V data flow in CRUD module

1. USER SEES V in picture means : C assigns variables from URL (user request, ee from URL query after "?" ) telling V what user wants and calls V method or includes V or URL calls page (C controls V).

2. M UPDATES V in picture means : V pulls data from M according C variables assigned in "1. USER SEES V".

3. C MANIPULATES M means : V (user request) may call C method for some state changes ordered in URL by user (USES in picture). Eg : table row update "Approve user comment" in msg module. User`s events are so handled in Controller class. View gets (singleton) or instantiates model object and pulls data from M. If we have user`s interactions (events) eg filter displayed rows (pagination is a type of filtering), than M-V data flow is only possible solution.

M-C-V data flow

Controller instantiates M and pushes M data to V. I do not see advantages compared to M-V data flow.

Disadvantage is : for pagination M-V data flow is only possible solution, C is fat in large modules (lot of code).

C in my msg (blog) module (M-V data flow ) has lot of code - routing, dispatching, but code is very simple.



Flow of control and M-V data flow in 3tier DAO code (abstract interface)

Step 1. Request is URL adress entered by user.
Response is HTML from Home view.
Step 2.TIER 1 CV data flow is Presentation layer Controller and View
Config_allsites (utl, utilities) is reusable (includ-able).

Home_ctr class extends utl (is utl = inheritance) is "ctrl+c,v reusable"

Home is view class, is "ctrl+c,v reusable".
Step 3.1 TIER 2 Model, Middle tier Business logic code layer.

Tbl_crud is module DB adapter class, "ctrl+c,v reusable DAO".

Tbl_crud has, uses Db_allsites or Db_allsites_ora or... composition (over inheritance and over traits), dependency injection).
Step 3.2 TIER 3 DAO Data Access layer
Db_allsites DB adapter class is shared, global on site level, common, reusable (includ-able) Data Acess ObjectImplements
Db_allsites_Intf reusable  (includ-able) DAO.

01_DDL_mysql_blog.sql 01_DDL_oracle_blog.sql 01_DDL_moj_adrs_MINI3_mysql.sql

How works R(ead) of cRud in B12phpfw (request and response)

  1. Router code in Config_allsites __construct method called from Home_ctr returns to Home_ctr user's commands (interactivity) decoded from URL request (ee calls "call_module_method").
  2. Home_ctr method "call_module_method" dispatches request (URL parameters from URL query string after "?" sign) to other Home_ctr method
  3. other Home_ctr method calls own view method to read table rows using DAO's (two classes in Step 3.) and display table rows, ee response is HTML from Home view class.

DAO's (two classes in Step 3.) : Tbl_crud and Db_allsites classes have same named CRUD methods cc, rr, uu, dd. Tbl_crud contains also business methods (business logic code is the largest and most complicated code, the only code which can not be standardized and implement interface - list of method names).

Tbl_crud and Db_allsites classes are independent thanks to Db_allsites_Intf list of methods in Db_allsites class. Persistant storage object variable (in dependency injected property palete object $pp1) is parameter of Db_allsites CRUD methods. This means that cc, rr, uu, dd CRUD calls in Tbl_crud may access any persistant storage - MySQL, Oracle, OS texts...

See  https://github.com/nazonohito51/clean-architecture-sample  - good picture, but for me to complicated code.

DAO's (two classes in Step 3.) are adapters : implementations - classes or methods which depend on interfaces, not on each other (ee do not depend on other classes).

Interfaces are abstractions, functionalities, features, ports. Interfaces in PHP are like UML diagrams or Oracle PL/SQL package : lists of class methods. PHP class is like PL/SQL package body.

DAO (Data Access Object) pattern (code skeleton pseudo code, uzorak, predlo┼żak) : separates a data resource's client interface (Tbl_crud) from its data access mechanisms (PDO in Db_allsites).

Ee DAO adapts a specific data resource's access API (PDO in Db_allsites) to a generic client interface (CRUD methods in Tbl_crud, not business methods which are to complicated, can not be generic, standardized !).

CRUD program generators (scaffolding or whatever they are called) are, in my opinion, unnecessary, sidetrack, almond operation from below because they cannot (and should not) generate Db_allsites nor Tbl_crud (business logic).


Links need globalization

Links in the addrs module are less transparent because they are not centralized - globalized -> more difficult to maintain than the routing table (array) in Home_ctr in the msg (blog) module.

Links show a lot about the code skeleton and about the programming technique. The following where links are, what they order to be done (not syntax) can be considered the standard for (web) programming. Syntax is specific for B12phpfw routing based on key-value pairs parameter_name-parameter_value. Eg :
       i/ex2/namep1/valparam1...  (QS constant is "?")
       Parameters "i" and "namep1" have values "ex2" and "valparam1". The number of parameters is unlimited.
       i means that ex2 (exsample 2) is method name in Home_ctr. Each module has only one controller (or more - not needed).

  1. In hdr.php eg <a href="<?=$pp1->module_url.QS?>i/ex2/p1/param1/p2/param2/">example2</a>
  2. After delete row in Home_ctr : utl::Redirect_to($pp1->module_url.QS.'i/rrt/') ; //to read_ tbl
    Simmilar Redirect_to's  in Tbl_crud in code "behind" user (Cre, Upd) interactions.
  3. In cre_row_frm.php call code "behind" : <form action="<?=$pp1->module_url.QS?>i/cc/" method="POST">
  4. In read_tbl.php <a href="<?=$pp1->module_url.QS.'i/cc/'?>">Add row</a>
    <a id="erase_row" class="btn btn-danger"
        onclick="var yes ; yes = jsmsgyn('Erase row <?=$id?>?','') ;
           if (yes == '1') { location.href= '<?=$pp1->module_url.QS.'i/dd/t/song/id/'.$id?>/'; }"
        title="Delete tbl row ID=<?=$id?>"
    ><b style="color: red">Del</b>
    <td><a href="<?=$pp1->module_url.QS.'i/uu/t/song/id/'.$id?>">Edit</a></td>
  5. In  upd_row_frm.php utl::Redirect_to($pp1->module_url.QS.'i/rrt/');
    and  <form action="<?=$pp1->module_url.QS?>i/uu" method="POST">
  6. In  Config_allsites.php public static function get_pgnnav($uriq, $rtbl = 0, $mtd_to_inc_view='/i/home/', $rblk=5)
  7. In  Db_allsites (mysql) and Db_allsites (oracle)  in method dd (delete row) :
     if (isset($pp1->uriq->r)) {
    self::Redirect_to(QS.'i/'. $pp1->uriq->r) ;


Why B12phpfw module dirs like Oracle Forms 6i fmb-s

For me framework  (menu and CRUD code skeleton) is group of code snippets for ctrl+c, v.

B12phpfw is diffrent from other (PHP) frameworks (menu and CRUD code skeletons) :

  1. Each module (is like Oracle Forms .fmb) is in own folder, has  one controller (or more - not needed), not all modules in 3 dirs: M, V, C.
    So my J:\awww\www\fwphp\glomodul\adrs\~~~~~ MINI3 ADRS ~~~~~.NPPSES
    contains scripts in only one adrs module folder : adrs.
    Global scripts are in : J:\awww\www\vendor\b12phpfw\ folder. Eg J:\awww\www\vendor\b12phpfw\Autoload.php
  2. Namespaces are FUNCTIONAL, not POSITIONAL (not dir tree).
    Eg namespace B12phpfw\site_home\www ; or namespace B12phpfw\module\adrs ;
    - B12phpfw\module is FUNCTIONAL part of namespace - we may write here whatever we wish what script does
    - adrs is folder in which script is (J:\awww\www\fwphp\glomodul\adrs\Home_ctr.php, http://dev1:8083/fwphp/glomodul/adrs/)
  3. Many other reasons, see on GitHub B12phpfw and demo (especially flow of control and data).






Site logo (if you wish) : in CSS background: url('data:image/png;base64,iVBORw0KGgoAA...QmCC');