I think I understand the concept of HMVC after reading this question and answer https://softwareengineering.stackexchange.com/questions/220480/hmvc-and-database-connections; an extract from an answer is below:
Let's assume you want to have a view that enables a user to make a comment to a blog post. You would have fields for name, e-mail, title and comment, but you also want to have a field country displayed as a dropdown. In the action that displays this view you would make a database query that loads the countries and then populate that dropdown. Which is ok, but it forces you to duplicate the query and the view required to display the countries if you need it in another part of your application. A better approach would be to create separate controller for countries with an action that returns a view with the dropdown and then render that action whenever you need to show a list of countries.
What I cannot wrap my head around is that if I can internally request a controller/model/view which just displays a widget (e.g. a country select box), doesn't that mean that by accessing that url from a browser will also just show that view?
How is this managed in HMVC, are routes defined as internal/external only, so matching an internal route with an external request would show a 404 page?
Is this generally how it is done and is the HMVC description/definition above satisfiable with the general use case of it in most web applications?
Showing the output of a sub-request in the browser shouldn't be a problem, so I wouldn't bother, especially that those URLs are not known by the user and it's safe to output the widgets separately.
Despite the above, you could, as @deceze mentionned, not attach those controllers to any routes. If you have a "default" route (matching all requests), then you would have to disable it.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments