This software provides a simple framework for PHP applications.
The framework's focus is on simplicity, performance, and flexibility.
The software lives at: https://git.albertleadata.org/rk4n3/wwwrig.git

• Lean footprint with minimalist view model
• Lean DAO model with popo (“plain ol' PHP object”) classes
• JSON RPC mechanics for service-level API implementation
• CSS baseline with minimal approximation of Google's Material Design

The wwwrig framework, or “the rig”, is far too lean to consider the boundary rigidity of MVC preferrable, and with the increasing relevance of responsive UI elements via ECMAscript + service calls, MVP ends up aligning more often.

That said, the rig does encourage a stripped-down model that borrows from both MVC and MVP, in a way that arguably aligns with most of the significant benefit of each, without any of the baggage (complexity, bloat, etc…).

The approach is oriented around taking care of basic entry points, and handing control over to the application's code as soon as possible.

Separation of concern is aided by the availability of a lean DAO mechanism, an equally-lean service API mechanism, and PHP's native ability to transparently inline static HTML.

The end result is a non-invasive foundation for the application that aligns well with, but also doesn't force, whichever aspects of MVC or MVP the programmer wishes to pursue.

The rig provides a unique and particularly lean approach to DAO, utilizing a single foundation class that simple and flexible popo classes can be derived from.

The programmer simply writes such a class, which programmatically defines a property map using simple foundation calls, and then adds any customization required.

For an overwhelming majority of usage, simply defining the property map is enough to get most DAO functionality “for free”.

Have you had your fill of wrangling XML into a state that can be used to generate code ?

Do IoC and AOP trigger your SAD and ADHD ?

If so, then you may appreciate the rig's complete avoidance of any such notions.

Seriously …
Moving application development from highly-structured programming languages into configuration solutions has many significant drawbacks for the programming process:

• Compile time errors are moved to runtime errors (this is the cause of many other problems)
• Type-safety is thrown out the window
• Refactoring is significantly more complex AND tedious
• Modern IDEs are very adept at editing code, but such tools are usually not available for editing configuration files
• Understanding config files requires learning a one-off DSL (Domain-Specific Language) - a waste of time
• Understanding config files requires following a tedious 'trail of breadcrumbs' of string identifiers
• Config files are parse-fragile - typos are easy to make, but hard to find (a bad combination)
• Config files are often not particularly legible or concise
• When working with revision control, monolithic config files that refer to multiple features will often be a source of contention between programmers working on different tasks
• When code is generated from config, any parts of code that either need, or could benefit from, customization can't be preserved across the code-generation cycle
• Code that simply reads minimal configuration, in contrast to code generated from configuration, enjoys most/all of the benefits of configuration, without these significant problems

The best way into the technical details is to dive into the code !

Have a look at rig.php and view.php, for starters.

That said, here's some other basics …

Here is a sample of what is expected for local configuration, as should be placed in the web footprint's etc/private/localcfg.php …

$pCfg = array(	'db_host' => 'yourdbserver',
		'db_db' => 'yourdbname',
		'db_uid' => 'yourdblogin',
		'db_pwd' => 'yourdbpassword',
		'path_www' => '/full/path/to/document/root',
		'path_app' => 'yourappfile.php',
		'path_pwd' => '/full/path/to/www/etc/private/htpasswd',
		'path_img' => 'img',
		'url_host' => 'www.yourdomain.com',
		'url_app' => 'http://www.yourdomain.com/yourappfile.php',
		'url_secapp' => 'https://www.yourdomain.com/yourappfile.php',
		'url_home' => 'http://www.yourdomain.com',
		'url_content' => 'http://www.yourdomain.com/img',
		'jwt' => 'yoursupersecretkey',
		'rbac' => 'yourRBACRegFunction',
		'ecmakit' => 'yourECMAkitOrigin',
		'ecma' => 'yourECMAkitRegFunction',
		'api' => 'yourapicontext',
	//	'api_auth' => 'true',
		'app_main' => 'lib/view.php',
		'app_pfx' => 'yourappname',
		'app_title' => 'Your App Title',
		'app_slogan' => 'Your App Slogan',
		'app_site_logo' => 'logo-site.png',
		'app_scope' => 'managed',
		'unix_login' => 'yourunixlogin',
		'unix_path' => '/home/yourunixlogin/bin',
		'ldap_host' => 'yourldap.server.com',
		'ldap_group' => 'yourldapgroupforaccess',
		'ldap_udn' => 'dc=yourdomain,dc=com',
		'ldap_bind' => 'uid=%s,%s',
		'ldap_xia' => 'ou=person,dc=yourdomain,dc=com',
		'ldap_filter' => '(&(objectClass=inetOrgPerson)(uid=%s))',
		'ldap_key' => 'ou',
	//	'app_ssnuid' => 'yourapp_adm',
		'bots' => array('bot1'=>'bot1password','abot'=>'abotpassword'),
		'map_emails' => array(	'default' => array( 'L1' => 'EM1'),
					'phone' => array( 'L1' => 'EM2') ) );

//	These are temporarily here for PhpRbac ...
class CfgRBAC {
	const HOST="yourdbhost";		// $host
	const USER="yourdblogin";		// $user
	const PASS="yourdbpassword";	// $pass
	const DBNAME="yourdbname";		// $dbname
	const ADAPTER="mysqli";			// $adapter
	const TABLEPFX="rbac_";			// $tablePrefix
}

This documentation will evolve as needed and as opportunity allows.