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

1. Firstly the server in development mode watches the Quale folders for changes to your application source, when detect a change or when a CLI command is issued it compiles the applications that have changed. It has a dependency tracker, so when a common files changes it may recompile several applications/pages.

2. When the compiler runs, it searches for files in a inheritable manner so you can have library files, that have been superseded with custom files, similar to what (CSS does for styles).

3. The compiler automatically includes files in the Models and Controllers directories ( again going up the directory hierarchy).

4. The compiler scans drop-in menu folders for menus options to add to the page's menu system.

5. In the application page, you construct the views from elements such as buttons, links ,menus , tables, containers, and other elements.

6. The elements can be controlled by sql code such as --{if:"(select count(ref) from todo_mvc where owner=session.id and status='')=1" }

7. The elements can execute SQL code such as <#:button --{title:"Clear Completed"} update todo_mvc set status='3' where owner=session.id and (status='1');>

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

9. 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.

10. 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 a later stage.

11. 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.

12. The compiler is now finished and the server will server the application...

13. 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, the JSON returns the name of the mustache file and the databases queries as one large JSON stream, this JSON is sent unaltered by the node server to the browser.

14. The browser now combines the Hogan template with the JSON, and injects that into the DOM and runs some JQuery init scripts on the result. Now the user has a fully functional web page filled fancy widgets.

15. 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 load the next page JSON.

And the (server) cycle repeats.

#How Qualia work

Each field is first exposed to regex searches against it's model definition, that regex adds qualia (properties) to the meta data of that field, then the qualia is matched to the classes of qualia you configure manually (and some pre-defined), then finally the qualia from the immediate context 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.

#How widgets work Each element has a style, that style is used to look up in a Style table for the code to be injected into the HTML, The style has a 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 as expected)

Now the code looked up from the style table, 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.