QZ Forms

Design Principles

If you wanted to maintain some data in the year 1987 and you had one of those then newfangled contraptions called a personal computer, you likely chose DBase III+ for the task. Using such a tool, you could create an application by defining fields and putting those fields onto data entry forms. If you put a numeric field in a form, it would only allow numbers; a text field would limit the text to the defined length.

So many decades later, so much great and powerful software has been written, but that simplicity has been lost. Too often, people use spreadsheets for maintaining data because that is easier to learn than Ruby on Rails. Programs like Ruby on Rails have a steep learning learning curve that takes experienced programmers many weeks of effort to learn.

Database Choice
Database neutrality is for wimps. Postgres Rulez! All features of PostgreSQL may be used.
Web user === PostgreSQL user
The application does not have a password hidden someplace. When a user logs in, it is Postgres that validates the user. When the application connects to Postgres, it is as the logged in user.
Text Strings
Form data is moved as text strings. Binary data is forbidden.
UTF-8
UTF-8 is the one true character encoding. All others are heresy. Data that is not UTF-8 is bad, should feel bad, and should aspire to be converted to UTF-8.
Avoid Duplicitous Redundancy
Metadata in Postgres, such as data type, should be carried through the process and not repeated. Javascript on the client should know the PG type.
No printf("<input type=text...
The application builds a web page as an xml tree of nodes with libxml2. At no time should the application print text for display.
Little Bobby Tables is welcome
http://xkcd.com/327/ Database transactions are to be done with prepared statements.
The target scale is 1PTD1PTU
QZForms should work well for one part time developer building an application for one part time user. The goal of QZForms is to make building a user interface to tables of data simple.