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
- 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:
- which calls a URL,
- which gets routed to PHP,
- which accepts the call and returns,
- either HTML or JSON, depending.
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.
- 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.
There are no secrets here... we even include the technologies we're using on our website: Laravel and jQuery