How does SQL MVC work?

##Brief: The compiler takes your application code which is little more than a few SQL statements, directives and properties and produces:

• All the database code as a single stored procedure, to be run to produce JSON output.
• a Mustache Template(Hogan) containing all the client side code to be filled with the JSON. When the two are combined in the browser.

The server node.js does very little other than pass JSON between the server and client. All the business logic remains in the database server.

You have full control of the client side look, feel and behavior, the default framework and theme is just to give you a quicc start.

##Detailed Workflow (diagram)[https://cloud.githubusercontent.com/assets/5948065/5691274/a9429c0a-98c6-11e4-929e-9f241abed783.png]

1. You develop the application by writing models,views and controllers which you place in files in the Quale application directory tree.

2. In development mode the server watches the Quale folders for changes to your application source, when a change is detected (or on a CLI command) it compiles the applications that have changed. It has a dependency tracker, so when a common file changes it may recompile several applications/pages.

3. When the compiler runs, it searches for files in a inheritable manner so you can have your local application files, files common to many applications, or framework library files. You can have library or common files that have been superseded by custom files in the local directories Detailed.

4. The compiler automatically includes files in the Models and Controllers directories ( again using the inheritance model).

5. The compiler scans drop-in menu folders for menus options to add links to menu systems.

6. Once the compiler has parsed the files it uses the SQL, and Quale statements, it does some substitutions and generates the stored procedure code to concatenate the data fields into JSON objects. The stored procedure includes code to accept input back from the fields that was generated or login information or navigation code when the user click a new page. The stored procedure is written to the database.

7. As the compiler parses the SQL, it also uses the Qualic information to generate the mustache template, that refers to the JSON fields that would be coming from the database at run-time.

8. The compiler builds the widget using the Qualia and element definitions and passing them through a server side mustache process (see how widgets work below...). The Mustache is saved to a file and is sent to the client as a pre-compiled Hogan template.

9. The compiler is now finished and the server will serve the application...

10. When a user logs-in the server passes the user name and password to the stored procedure, the stored procedure authenticates this in the database and executes the rest of the page, which returns a single JSON stream with the name of the mustache file and the databases queries in one operation, this JSON is sent unaltered by the node server to the browser (using web sockets).

11. The browser now combines the Hogan template with the JSON, and injects that into the DOM and runs a JQuery init script on the DOM (div). Now the user has a fully functional web page filled fancy widgets.

12. When the user saves some information or clicks a navigation element, the info or nav-id is passed almost unaltered to the stored procedure, which validates it against the updates that are allowed for that page, ( The security context is obtained from the primary key cache table), The database is updated, and the stored procedure uses the nav-id to locate the next page.

And the (server) cycle repeats.

#How Qualia works.

Each field in the model, (or when used in a view or controller) is exposed to regex searches against it's model definition, this adds qualia (properties) the field, then the specified qualia from the field context in the table model is added, then the qualia is matched to the general classes of qualia you specify (and some from the framework), then finally the qualia from the context where it is being used is added, this forms a cascading qualia inheritance model (similar to css properties). So when you issue "select field from table" ,the compiler has assimilated all the necessary information of the field and the table to produce a sensible user interface.

#How the user interface works.

###Element dictionary Each framework provides a element dictionary, and your application Views can add custom elements.

Each element (display, input ,link/menu/button, table/container) has an action, type, style and substyle property, which is used to look up from the element dictionary the code that will be injected into the HTML (and JS if needed).

The process follows an inheritance model (Style/SubStyle/Action) also so if the chosen style is not available a lesser style will be inherited down to simple text edit or display boxes. So when you design your models you can specify styles that wont exist yet and will be created later, meantime the app will still run (substantially) as expected.

Now the code looked up from the element dictionary also passes through a mustache template engine, with the context of the Qualia of the its associated field elements and its table context available to the template, so a creative UI creator can extract a lot of info and create the element such that it is responsive to a wide range of qualia.

###Program flow control The language is very declarative, so it does not have loops (it does not need then either!), but it does have conditional execution: Any element can be enabled or disabled/hidden by conditional sql code such as

ifquery (select count(ref) from todo_mvc where owner=session.id and status='')=1)
print Only one Left
endquery

The button and link elements can execute SQL code when the button is pressed:

button(title:"Clear Completed")
update todo_mvc set status='3' where owner=session.id and (status='1');`

The tables have full CRUD ability (set per field according to the qualia, Action:["View"|"Edit"|"Hide"|"Link"]).