Differences

This shows you the differences between two versions of the page.

--- 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 ======
 This software provides a simple framework for PHP applications. \\
@@ Line 13: / Line 13: @@
 ====== Concepts ======
 ===== 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...). \\
-The approach is oriented around taking care of basic entry points, and handing control over to the application's code as soon as possible. \\
+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...).
-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 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.
 ===== 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 ======
+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 ====
 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>
 <code>
@@ Line 79: / Line 116: @@
+==== Don't despair, more to come ... ====
+This documentation will evolve as needed and as opportunity allows.

Albert Lea Data Wiki

User Tools

Site Tools

Differences

Page Tools