Routing in nested MVC

[GAJ]

Hi

I relatively new to MVC and trying to understand it all by coding my own MVC framework. I already have coded my (own variant) MVC application: a router calling controllers each creating CRUD(L)* forms (views) onto separate db tables. Now I want to create a dashboard with multiple forms each modifying a separate database table. I already have the ability for one controller to call another controller ad infinitum. However when I press "modify" on one of the forms I do not know how to route (call the router) to rebuild the dashboard restoring all the other forms (ie other controllers) to the same state they were in when my target form requested a modification.

Basically I don't know how to go about routing in a hierarchical or nested MVC framework. Should I design a complex (non-linear tree-like) URL request that captures the state of my dashboard and have a very complex router that can decode it? Should each action be idempotent or should I use state in the session to make the request URL easier?

*CRUD(L) a view with different forms for CRUD and L(ist) operations each invling different controller methods.

I have tried searching under "HMVC" (but that seems to mean "modules") and "nested MVC" but for both terms I mostly get referred to established frameworks.

Cheers

GAJ

[requinix]

Sounds like you should code it with a view that renders the different forms, a controller that handles that one view, and when submitted the controller checks the form data to decide which other controller should be used to handle the requested action.

The concept you're working towards is something like partial views, or using components instead of view pages. Not a common thing to see with a PHP MVC framework. This scheme tends to be handled in more of an event-driven way: the view and controller are more closely coupled and set up for a collection of view "components", the view tells the components to render themselves (eg, a "render" event) and the controller tells components to handle form submissions (eg, a "submit" event). Components can contain other components. This starts to get complicated because you need a way to separate the different components' form data from each other, meaning form rendering helpers that make it easier to deal with form data naming schemes; a top-level component Foo may want a "name" form field, the rendering helper actually renders it as a "Foo" prefix + "name", and later some mechanism decodes the form data and component hierarchy to make sure that Foo properly gets the "name" it expects.

But that's complicated.

If you're learning MVC then try to stick to the standard MVC ways of doing things. In this case, the standard solution is to have your view render all of the forms and fields itself, then the controller receives all of the data and decides what to do.
Consider that it's perfectly fine to create for yourself a sort of "form for table X" class to help reduce the amount of work the controllers and views have to do on their own.

[Strider64]

Another pattern you might want to look into is Active Record Design Pattern. That is what I use as it's database data driven and once the you get the insert, update and delete working it's basically just sending the right query or sql to the database. The view is usually another class.  It's nice for a small website, but I wouldn't want to use it on a big project though it does lend itself to modifications more easily in my opinion and being a little more haphazard for people who like that aspect of coding. 😃  Though MVC does lend itself to better to structure than ARD and some people consider Active Record Design Pattern an anti-pattern. Though I disagree with that as if it was the case then you might as well stick to procedural coding in my opinion.  Some more info -> https://en.wikipedia.org/wiki/Active_record_pattern

Edited June 5, 2021 by Strider64

[maxxd]

I just want to point out that AD and MVC aren't mutually exclusive. Laravel, for instance, is an MVC framework with a built-in AR ORM (Eloquent). Patterns intermingle and build on each other to create a full code base, so you don't need to discount or dismiss AR if you decide to use MVC, and vice-versa.