About The Architecture

Good Morning!

My business partner, Adam, asked me about the basic architecture of our application.  I proceeded to explain MVC, from an operational perspective.  Not how the code is organized, but how the operation of the application works.  How actions begin with the user, cycle through the system, and come back!

So, here goes...

• When the application loads up, all the js are loaded, and the menus
• So.. When you click a menu item. You run a public function in a name-spaced JavaScript file. An example would be clients.js. (clients.load)
• clients.load hides whatever is on the screen and fetches the index page for clients.  It does that by calling a URL, and post the response to a div on the page.
• All URL calls end up in the routes table.
• Thats defined in the routes directory in the application code.   (Web.php, I believe.)
• The route for /clients gets sent to the resource client route entry.
• Which goes to the client controller. 
• ClientController.php is in the controllers, and that particular endpoint triggers the show call.
• Resource routes have a standard base set of calls it handles. (Table is not standard.... That is why it has its own routes table entry.

Anyway... If you look... The way things work is that a user action:

1. triggers a JavaScript function, 
2. which calls a URL, 
3. which gets routed to PHP, 
4. which accepts the call and returns, 
5. either HTML or JSON, depending.

Several loops can happen... Then it all waits for the user to start some other action.

Notable exceptions include:

• Tables loads:  All table loads (/table) happen as separate cycles, and return JSON.  This is so the table load can return a single page, and can request sort, filter and page changes without redrawing the table.
• Select-list loads:  Where select-list options are either volatile, or long, the select list load is done as a separate (/selectlist) call, allowing for filtering.
• Table headers:  The table tool we're using requires the data to be mapped in the JavaScript, and we do this by attaching JavaScript blocks to the index page HTML.  
• Our application is multilingual at the user level, so only the server knows what language the header label should be in. 
• Some of our screens are user-configurable, so the table layout is only defined at run-time.

Adam expressed a concern about whether this was proprietary, and whether we should even do this as a blog post.  I said no... not only is this the proper way to do this kind of thing, but anyone who is not using this methodology isn't actually building a web application... Just a series of pages!
There are no secrets here... we even include the technologies we're using on our website:  Laravel and jQuery