Revised November 2021 October 2020, December 2019. Original post was published in February 2019.
Download https://github.com/slavkoss/fwphp/ . My articles before this are not needed to learn B12phpfw.
November 2021 version 8.0.0 (requires PHP ver. >= 7). Download contained many learning examples, but no more because three modules – packages : Mnu (menu code skeleton), Msg (Blog – compound module) and Mkd contain enough (not to simple) PHP code for learning, create large sites CRUD pages and own WYSIWYG web editor. To simple learning code (frequent in learning sources books and internet) is dangerous, leads to wrong coding, which is one of reasons why I have 8 versions. Version 8 is in my opinion smallest code to learn serious web programing.
What’s new in version 8 :
- Autoload.php is refactored, much simpler, see old z_NOT_USED_TO_COMPLICATED_Autoload_1stVersion.php
This is good case showing that first code versions are to complicated code – very frequent case – which is one of reasons why I have 8 versions. - Shares are not any more in \zinc folder but in in vendor folder eg \vendor\b12phpfw\Autoload.php (below web server doc root eg J:\awww\www\). Site roots are on same place in folders hierarchy eg \fwphp (may be named site_x). Also group of modules eg \fwphp\glomodul. Also modules eg \fwphp\glomodul\blog – dir like oracle Forms form module.
- PHP 8 (ver. 7 still works) and Bootsrap 5
<?php
http://dev1:8083/fwphp/www/
// J:\awww\www\fwphp\www\index.php
namespace B12phpfw\site_home\www ;
use B12phpfw\core\b12phpfw\Autoload ;
//1. settings - properties - assign global variables to use them in any code part
$module_path = str_replace('\\','/', __DIR__) .'/' ;
$site_path = dirname($module_path) .'/' ; //to app dir eg "glomodul" dir and app
//to web server doc root or our doc root by ISP $module_towsroot = eg '../../../'
$wsroot_path = dirname(dirname($module_path)) .'/' ;
//or $wsroot_path = str_replace('\\','/', realpath('../../')) .'/' ;
$shares_path = $wsroot_path.'vendor/b12phpfw/' ; //includes, globals, commons, reusables
$pp1 = (object)
[ 'dbg'=>'1', 'stack_trace'=>[str_replace('\\','/', __FILE__ ).', lin='.__LINE__]
, 'module_version'=>'8.0.0.0 Mnu' //, 'vendor_namesp_prefix'=>'B12phpfw'
// $_SESSION["TrackingURL"]=$_SERVER["PHP_SELF"];
// 1p. (Upper) Dirs of clsScriptsToAutoload. With 2p(ath). makes clsScriptToAutoloadPath
// 2p. Dir name of clsScriptToAutoload is last in namespace and use (not full path !).
, 'wsroot_path' => $wsroot_path // to awww/www (or any names)
, 'shares_path' => $shares_path // to b12phpfw, b12phpfw is required dir name
, 'site_path' => $site_path // to fwphp (or any names)
, 'module_path' => $module_path // to fwphp/www (or any names)
//
, 'glomodul_path' => $site_path .'glomodul/'
, 'examples_path' => $site_path .'glomodul/z_examples/'
] ;
//2. global cls loads classes scripts automatically
require($pp1->shares_path . 'Autoload.php');
new Autoload($pp1);
//3. process request from ibrowser & send response to ibrowser :
//Home_ ctr "inherits" index.php ee inherits $p p 1
$module = new Home_ctr($pp1) ; //also instatiates higher cls : Config_ allsites
exit(0);
<?php
// J:\awww\www\vendor\b12phpfw\Autoload.php
namespace B12phpfw\core\b12phpfw ; //Dir name is last in namespace and use
//use B12phpfw\dbadapter\post\Tbl_crud ; // as Tbl_crud_post ;
class Autoload
{
protected $pp1 ; //M O D U L E PROPERTIES PALLETE like in Oracle Forms
public function __construct(object &$pp1) {
$pp1->stack_trace[]=str_replace('\\','/', __FILE__ ).', lin='.__LINE__ .' ('. __METHOD__ .')';
$this->pp1 = $pp1 ;
spl_autoload_register(array($this, 'autoloader'));
return null ;
}
function autoloader(string $nscls)
{
//$nscls is namespaced called cls name eg B12phpfw\module\book\Home_ctr
$DS = DIRECTORY_SEPARATOR ;
$nscls_linfmt = str_replace('\\',$DS, $nscls) ; //ON LINUX
$clsname = basename($nscls_linfmt) ; //eg Home_ctr, Config_ allsites, Db_allsites
$module_dir = basename(dirname($nscls_linfmt)) ; //eg Home_ctr, Config_ allsites, Db_allsites
//echo '<pre>$nscls='; print($nscls) ; echo ' $module_dir='; print($module_dir) ; echo '</pre>';
switch ($module_dir) {
case 'b12phpfw':
$clsscript_path=dirname($this->pp1->shares_path).'/'.$module_dir.'/'.$clsname .'.php' ;
break;
default:
$clsscript_path=dirname($this->pp1->module_path).'/'.$module_dir.'/'.$clsname .'.php' ; break;
break;
}
//echo '<p>$clsscript_path='; print($clsscript_path) ; echo ' SAYS: '. __METHOD__ .'</p>';
require $clsscript_path;
}
}
2020.09.30 DONE version 7.0.0 (declare(strict_types=1);).
DBI is improved with trait Db_allsites instead class Db_allsites. Each DB (persistent storage) adapter-class named Tbl_crud :
- use B12phpfw\core\zinc\Db_allsites
- implements Interf_Tbl_crud
This means that :
- eg blog module in blog folder, works much easier with more model classes ee Tbl_crud -s, ee with own Tbl_crud and with other tables Tbl_crud.
- eg sole module controller class Home_ctr extends class Config_allsites, no more extends also two DB CRUD classes which is unnatural (but seems easy because logically : all is in Home_ctr).
B12phpfw core (CRUD) code – How to get ONLY banana ?
It is not easy to see need to why convert code from procedural MVC to OOP MVC with namespaces and autoloading. For navigation (url-s, links) code procedural and OOP is same – OOP does not help. Procedural MVC user module code is more clear and readable. So why is OOP better ?
Some say: “is OOP mistake ?” – eg lack of reusability in OOP – to get banana (some method or attribute) you get also gorilla holding banana and whole gorilla`s jungle (all higher classes with complicated dependencies). It is why B12phpfw code skeleton is for CRUD modules (is not required for Mnu and Mkd modules but I put both on B12phpfw code skeleton).
Interfaces help to get ONLY banana, but coding is complicated – I could find only strong-talk-weak-work code examples about advanced use of interfaces.
- My not complicated interface Interf_Tbl_crud I made to standardize coding Tbl_crud model adapter classes and Db_allsites shared model class. Each simple (ee one table) module like “invoice items” module has own dir and own Tbl_crud class leading to more than 100 Tbl_crud.php model adapter classes scripts in big application (eg material and financial book keeping).
J:\awww\www\vendor\b12phpfw\Interf_Tbl_crud.php (... hits) Line 20: static public function get_cursor( //instead rr Line 28: static public function cc(object $pp1, array $other=[]): object ; //create row Line 31: static public function rrnext(object $cursor ): object ; //read next from $c=get_cursor Line 34: static public function rrcnt( //string $sellst, //read count rows in table ... - With DBI trait Db_allsites I eliminated two higher DB classes. So if banana (some method or attribute) is
get_cursor(read) from more tables it is not in two higher DB classes which seems simplest solution but caused complicated coding in version 6. Eg invoice module works with two (or three – bill) tables : invoice and invoice_items.get_cursorbanana is not in jungle (two higher DB classes) any more, gorilla and jungle is only one abstract class Config_allsites which is de facto assigning $pp1 = properties (Oracle Forms form property palete made global).- Banana $pp1 = properties palette may cause difficulties in aggregate (compound, composed, multiplex) modules like Blog, Invoice… but $pp1 is inevitably (imminence, necessity) gorilla-jungle and can not be further simplified. I worked 20 years with $pp1 and globals jungle (Oracle Forms 6i) which i not so well accomplished as in B12phpfw .
See https://phpthewrongway.com/, or Joe Armstrong why OOP sucks http://harmful.cat-v.org/software/OO_programming/why_oo_sucks.
Similar “simplest solution” three dirs M,V,C is (I think) bad, I have opinion -:) for 3dirs lovers who put in foreground coding technic (M,V,C code separation) instead pages (functionality, business logic , eg invoice page).
During winter 2019/2020 year (much to late because I tested lot what others did) I made Version 6. of menu and CRUD PHP code skeleton (own framework named “B12phpfw”) – core code is about 50 kB.
I also made posts module “Msg” with posts edited with WYSIWYG Markdown SimpleMDE editor (or HTML WYSIWYG Sumernote editor or … any editor you wish). Msg module is based on B12phpfw, also very small code.
B12phpfw code skeleton and Msg application on B12phpfw skeleton is minimal PHP code to learn (medium/advanced knowlege) PHP !
Why ?
- I do not like proposed solutions in best php frameworks (Laravel, Simfony, Yii…) and learning sources (internet, books).
- I think that eg module invoice php code should be in own folder like Oracle Forms form invoice.fmb instead all forms/reports in 3 folders: M, V, C).
- I think that should be simple/fast/professional : shares (globals), routing, dispaching, classes loading , web rich text editing – it is why I spend many hours coding my B12phpfw (huge time wasting which should do software authors, not sw users-programers like me).
Compared B12phpfw Msg (blog) module and TraversyMVC blog module and Mini3 module URLs Youtube songs adresses
Why I do not like proposed solutions in existing PHP frameworks and what I did to (I hope) improve fw code. Red colored features and three asterisks *** are main reasons for B12phpfw, but I improved also other features.
TraversyMVC (has video) and Mini3 are simplified, with some (many?) differences Laravel, Simfony, Yii… B12phpfw is much more different – see red colored features.
| Feature | B12phpfw | TraversyMVC and Mini3 |
|---|---|---|
| 1. ***Modules in own folder like Oracle Forms .fmb | has – it is main reason for B12phpfw ! | has not like Mini3 – all forms/reports in 3 folders: M, V, C |
| 2. Name spaced classes (functional name spacing) | has | has not – no functional, no positional (paths) name spacing, Mini3 MVC PHP fw which is in my opinion better than TraversyMVC : https://github.com/panique/mini3 has name spaced classes |
| 3. Number of folders (my opinion) | optimal | to many like Mini3 |
| 4. Minimal PHP code to learn (medium) PHP (my opinion) | optimal (but we could add additional code) | good but not enough like Mini3 eg see WYSIWYG, globals… |
| 5. Functional methods, attr. etc naming (my opinion) | good | could be better |
| 6. ***Global classes, methods etc (my opinion) | good | bad like Mini3 |
| 7. (Posts edited with any) WYSIWYG editor | has | has not like Mini3 |
| 8. ***Home_ctr or Home_mdl CRUD layer methods do not know for underlaying Db_allsites layer PDO methods, MySql, Oracle… | has much improved | has not like Mini3 |
| 9. OOP | has | has like Mini3 |
| 10. namespaces (own PSR-4 (or Composer’s) autoloading classes scripts) | improved | has not, Mini3 has |
| 11. ***All scripts are included (ee no http jumps except some jumps to other module) | has | has not, Mini3 has, B12phpfw took it from Mini3 |
| 12. jQuery only for Bootstrap 5 | yes | yes, Mini3 has own CSS |
| 13. no AJAX, no JSON | yes | yes, Mini3 has basic jQuery AJAX explained |
| 14. server side validation | has | has like Mini3 |
| 15. authentification (log in / out) | has | has, Mini3 has not |
| 16. authorization (only logged in users may execute some code ee CRUD code…) | has | has, Mini3 has not |
| 17. ***Own debugging very simple and useful : msg in pre tag or popup JS msg). xdebug also helps. | has | has not like Mini3 |