User Tools
mantis:wwwrig:start
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
mantis:wwwrig:start [2018/11/01 22:31] admin |
mantis:wwwrig:start [2018/11/05 13:28] (current) admin |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | <typo fs:xx-large; fw:bold>wwwrig</typo> | + | {{:mantis:wwwrig:sailboat.png?240}} <typo fs:xx-large; fw:bold>wwwrig</typo> |
| ====== Introduction ====== | ====== Introduction ====== | ||
| This software provides a simple framework for PHP applications. \\ | This software provides a simple framework for PHP applications. \\ | ||
| Line 13: | Line 13: | ||
| ====== Concepts ====== | ====== Concepts ====== | ||
| ===== No MVC, at least not really ... ===== | ===== No MVC, at least not really ... ===== | ||
| - | The ''wwwrig'' framework, or "the rig", is far too lean to consider MVC preferrable. | + | 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 provides most of the significant benefit of each, without any of the baggage (complexity, bloat, etc...). | + | 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. | The approach is oriented around taking care of basic entry points, and handing control over to the application's code as soon as possible. | ||
| Line 30: | Line 30: | ||
| For an overwhelming majority of usage, simply defining the property map is enough to get most DAO functionality "for free". | For an overwhelming majority of usage, simply defining the property map is enough to get most DAO functionality "for free". | ||
| + | ===== Code ... not Config ===== | ||
| + | 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 | ||
| + | |||
| + | ------ | ||
| ====== Technical Details ====== | ====== Technical Details ====== | ||
| + | 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 ... | ||
| + | |||
| ==== Configuration File ==== | ==== Configuration File ==== | ||
| Here is a sample of what is expected for local configuration, | Here is a sample of what is expected for local configuration, | ||
| Line 89: | Line 117: | ||
| ==== Don't despair, more to come ... ==== | ==== Don't despair, more to come ... ==== | ||
| - | + | This documentation will evolve as needed and as opportunity allows. | |
mantis/wwwrig/start.1541129506.txt.gz · Last modified: 2018/11/01 22:31 by admin
Page Tools
