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:25] 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 24: | Line 24: | ||
| ===== DAO ... not DOA ===== | ===== DAO ... not DOA ===== | ||
| - | 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". | + | 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". | ||
| + | |||
| + | ===== 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, | ||
| - | as should be placed in etc/private/localcfg.php ... | + | as should be placed in the web footprint's ''etc/private/localcfg.php'' ... |
| <WRAP prewrap> | <WRAP prewrap> | ||
| <code> | <code> | ||
| Line 84: | Line 116: | ||
| + | ==== Don't despair, more to come ... ==== | ||
| + | This documentation will evolve as needed and as opportunity allows. | ||
mantis/wwwrig/start.1541129149.txt.gz ยท Last modified: 2018/11/01 22:25 by admin
Page Tools
