Framework overview

'Dolphy' : My lmvc2 python framework.
 
Dolphy is a Model-View-Controller framework in the python programming language. I use the
abbreviation 'lmvc2' for Loader-Model-View-Controller-Config, since I put a lot of emphasis on
configuration and the loader is king. "Data Drives It".
 
Dolphy grew by the process of developing many projects for clients. The name was inspired in a
round-about way by django. As django is named for Django Rheinhart, who introduced the guitar to
jazz, dolphy is named for Eric Dolphy, who introduced the Bass Clarinet to jazz. Like Rheinhart,
Dolphy was a a genius and their memory influences those of us who aspire to the best and the most
creative. 
 
Dolphy is not yet registered at github and is a tentative title. Should it be 'taken', I've got
another in mind, but I'm not giving it up here.
 
The core of dolphy is three top-level files. The loader, the filemapper and the configuration
bootstrapper. They will be installed in the topmost directory of a project.
 
The Configuration Bootstrapper
The source file is always named 'Site.py'. Its main job is 
1)To add the search paths for other python modules in the project so that they can be imported
initially by the Loader and then by subsequent controllers and data models. This removes some of the
server configuration issues that can be burdensome for deployment of python to remote servers.
 
2)Initialize a series of control values that are in turn used by another module (erh) which is
visible to any number of the controllers and models.  Unlike PHP, python does not have a symbol
table that is visible to the entire running process. This is a _good_ thing IMHO.
 
3)Imports the the `siteConfig' module from the `config' directory and therefore makes the remainder
of project-wide values available to other modules.
 
The Loader
Source file is projectnameLoader.py and is executable.
The loader
1)Imports `Site' (the bootstrapper configuration module).
2)Initializes and sets up the 
  a) CGI environment.
  b) database environment.
  c) URL handling environment.
  d) Logging environment
3)Authenticates users
4)Resolves the target controller.
5)Sets up the outer working environment which 'contains' the other environments as well as indexable
values from the config/config module and passes the assembled environments as part of a container
object to the controller.
6)Imports the target controller. All controllers have a process() function. 
7)The controller.process is called and the outer working environment object
is passed as the argument.
8)Traps errors, saves logs, cleans up.
 
The File mapper
Source file is fileMap_projectname.py
1)Initializes server/workstation specific paths to files.
2)Provides names of all files, including python, javascript, css, html and any
others.
3)Establishes relationships between all files in the project.
4)Maps URL aliases to controllers
 
The file mapper is used for remote synchronization and deployment, mapping out documentations of
dependencies and other tasks. It can be leveraged by the IDE/editor of choice for 'rsync-like'
features.
 
Dolphy is self-documenting and the documentation module, which is a component of every dolphy
project is enabled by the Filemapper. More about that later.
 
Controllers
Views (or templates) have as source html or sometimes text files. A view is processed and the output
is a file of data structures that is cached on disk and for performance will not be reprocessed
unless
1)The timestamp of the source changes 
OR
2)An override is passed to the view loader.
Content is inserted by either 
1)Replacing tokens. A convention is , but other formats are
possible.
2)Injecting content directly into form elements (widgets). Requires no special 'extra-html' markup
or pseudo-markup. Validation of data in form elements is enabled by strings for the title or src
attributes. The strings are decomposed into key/value pairs in which the key and value are separated
by a ':' (colon) and pairs separated by a ';' (semicolon). Multiple values are separated by '|'
(pipes). These are used by my javascript data validator and provides 'psuedo-types' which define
text masks.
 
Think of these as property lists.
Example 1 - A text input field which must be numeric:
<input type="text" name="age" size="20" src="req:1;label:Age;type:uint">
Input is required. Input must be an unsigned integer. 
 
Example 2 - A text input field which must be the same as another
(confirmation):
<input type="text" name="user" size="26" src="req:1;label:User Name;sameas:confirm_user">
Input is required. Text must be the same as text field ID="confirm_user"
 
Example 3 - A text input field which accepts a date 
<input type="text" name="Sale_Date" size="20" src="req:1;type:date;label:Date of Sale">
 
Input is required. type:date means validate for mmmm/dd/yy. And the view
loader will insert the javascript code to generate a datapicker widget. The
widget will be inserted following the tag.
 
Example 4 - A file upload field.
<td align="left"><input type="file" name="notice_pdf" size="50"
src="req:0;label:PDF or JPEG File;ft:.pdf|.jpg|.jpeg;path:source_PDF">
Input is not required. File must end with any of the following extensions: '.pdf','.jpg','.jpeg'.
path:source_PDF tells the javascript validator to store the file name in a hidden field
with ID="source_PDF"
 
Example 5 - Reading data from a database into a select list
"link:city&Composite_ID@GeoCities" as a component of a property list tells the framework
to load data into the select list with the city and Composite_ID columns in table GeoCities.
 
The Installer 
This is a free-standing executable that assembles files for a
project startup .
Using as input a 
1)Client directory file which contains project values
2)A client name
3)A project name
4)A parent directory.
Creates
1)Directories
2)The Loader
3)The File Mapper
4)The bootstrap configuration file
5)config/config
6)config/siteConfig
7).htaccess
8)File list
9)Various templates for views and for controllers.
10)The data model.
 
The data model contains a function called build_input_forms() which when invoked, creates a
directory of prototype HTML documents containing input for all tables in a database. This can save a
lot of time in assembling forms for inputting or editing data from databases.
 
Documentation Browser
All installations produce a documentation browser. This follows the 'map' created by the File Mapper
to provide documentation in a heirarchical manner for all resource files in the project. Python
docstrings are used. Special tokens in each other filetype are defined for the production of
documentation.
 
When any filetype is loaded by the documentation browser, the rules for the tokens are written at
the beginning of presentation.  The doc browser is available to privileged users of the project
only.
 
Remote setup
Dolphy is designed to originate on a workstation and to be deployed or pushed to a remote
server. Since the filemapper employs FTP, a component of the framework is a command-line
utility which can be run from the command-line via SSH on the remote server to configure
the target directory structure.
 
And there's much more, but this should suffice for now.