ok I'll give this a shot.

I'm using a .htacces file so all requests go through index.php. Lets go with /myThingie/grid. That will supply the assets such as the css and javascript, and an initial html page with basically nothing on it, so that the JS can have something to work with.

It also receives a "src" variable which will be "/myThingie/gridData" which is accessed via ajax. This will supply the viewmodel. Once that is loaded, it will do a second ajax request to

"/myThingie/getAll?param1=whatever".

I wanted it to be fewer than 3 requests but right now this is just simplifying things, and reducing the number of requests can be a future optimization. I tried doing it before and it broke another feature (initial search parameters) and I decided it wasn't worth it now, I'll try again later, because it will be somewhat more complicated than you would think to combine these two functions into one request.

So, to serve any of these requests, it goes through index.php, which does all the normal things like vaidate the session, load up the autoloader, define some constants, break apart the request uri, route it, and all that stuff. The router function is basically how it determines what to do. What it will do is look for "myThingie" in a few different places. And based on where it is located, it knows what to do with it. So, if there is a specific controller for "myThingie", it will load that controller. If it doesn't find one, it checks if there is a viewmodel for "myThingie", and if there is one, it loads the "autoController" which is basically just my api. That is what houses /getAll, /insert, /add, etc.... The autocontroller loads the viewmodel up and the viewmodel supplies everything needed for all of the api functions to do their job. Such as table name, field names, actions which are availble, and much more. So for instance I could have two separate viewmodels that use the users table, but with different fields, or different actions. It also defines a model to use in addition to the viewmodel. The model is essentially 1:1 with each table in the db. This is just how I did it. Each table has a model. The model defines the table, fields, sql language to generate the field in the db, what kind of data it is, etc.

So, for instance, if the request is /user/add?name="john", it will hit the index. the index will say, "is there a users controller? Yes, there is. It will look for the function add. When it doesn't find it, it will default to the parent class, which is the autocontroller, where it will find Add. Or alternately, it won't find a users controller, and will look to see if there is a viewmodel, find it, and load the autocontroller. The auto-controller will then load the user viewmodel, which will inform it of the existence of the user model. The autocontroller will pass the parameters to the model and attempt to insert the data. The model base class is designed to clean the data. So, either there is a "name" field or there isn't. It will only look for data that matches its fields, it won't take any data that it doesn't want. So, it will find "name", and "name" is defined as a string, so it will run all the cleaning functions for strings, before attempting to validate. Validate is also in the base class (note that these can be overwritten or amended in the child class), Validate will check to see if it has all of the necessary data to insert the request. If it does, it will build the query from the model's "fields" attribute and the available parameters.

It will send the response back, and the javascript will have a function waiting for the response, which will trigger a modal component with success or failure message, and other actions based on that.

This is basically my app.