0

I'm new to HMVC and whilst tutorials are great about dealing with the overall details of keeping modules separate and only letting controllers communicate, they aren't so great at explaining the little details of what should go where.

This is an example I'm currently faced with. I'm using Kohana as my framework, and building an admin control panel for a website. The first thing I've done is to set up the page. All admin pages are in the Admin controller, with each page being an action. That's all fine and I've created a basic login page based off Kohana's Auth system.

Now I'm coming to my first proper page, the accounts page. It needs to list all accounts with links to create new ones and edit / delete existing ones. Fairly straight forward, I have a view for the page, and then create a new module for an account. But then here's where the tutorials let me down, when I need to fetch a list of all accounts. By design the new module should be a single instance of an account, so when I'm loading all accounts I'll end up with an array of instances, one for each account. But where is this array? Do I create a factory that controls this and if so, where does the factory sit in the HMVC structure?

Assuming that's resolved and I have my array of accounts available to the page controller, what about if when loading these accounts I need to filter them? Most pages listing accounts or products or anything like that will have a search at the top. Now the search is part of the page, so it should belong to the admin controller, right? So how do I get that information to the accounts model when it's loading all those accounts?

Before HMVC I would have just written the where clause of the query in the admin controller and passed that to the accounts model, but that's not an option in HMVC as the admin controller shouldn't have any knowledge of the structure of accounts. So now do I just pass the search results as variables into the accounts controller? Does the accounts controller just load this information directly from GET/POST (even though the search belongs to the admin controller)? What is the recognised way to handle this in HMVC?

I've tagged this PHP because that's what I'm using, and I'd appreciate any examples to be in PHP.

  • I don't pretend to be HMVC expert. In my experience, there are as many different definitions of these sorts of patterns as there are developers who implement them. I don't understand from your question why the AccountsController would not have control of the accounts search form. – Cerad Sep 19 '14 at 15:29
  • @Cerad Would it? As I said I'm new to this. I would have thought the search form would belong to the page, not the account. I could be wrong though. If the search form belongs to the account, what about the listing view (where each individual account is output to the page)? Does that also belong to the account rather that the page? If so I guess that solves my whole dilemma above about passing the data through. – Styphon Sep 19 '14 at 15:47
  • Your terminology (page) is a bit confusing. The accounts search form could be on the same html page as the list of accounts. Changing the search parameters would change the list of the accounts. The Account page itself would only show one account. If you really need the account search form and the account listing to be on different html pages then add an AccountSearchController. In broader terms, I would focus on what seems to work as opposed to trying to follow some ill-defined pattern. Afterwards you can go back and say "ah ha" my code follows xxx pattern. – Cerad Sep 19 '14 at 16:00
0

It might help if you keep in mind there is a distinction between creating an object and using that object. The former is a looser coupling than the latter.

With your specific example, I would expect to see an AccountsController (note the plural) that knows how many accounts there are and creates a view that determines where each singular account view will be located and its size. This controller will also manage the search view and and an array of AccountControllers. Of course, this plural controller doesn't actually create individual account views. It leaves that up to its child controllers.

When the plural controller creates it's child controllers, it hands the appropriate model information to the child. This model data could be an account or maybe just an account ID. It is the child controller's responsibility to use the account properly or maybe even build/retrieve a new account object based on the information provided.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.