CodeIgniter Forums

Full Version: HMVC the right way ?!
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4
So guys here the thing,

I like to use HMVC (Wiredesignz) a lot. It gives me simple module folders which can be copied and pasted to other projects and put to work with almost no effort. Very handy to reuse code this way.
And using widgets gives me an easy way to use parts of other modules. 

And here's alway where the commotions starts...

Controllers calling controllers is bad... I get it. CodeIgniter is coded a certain way with reason.
But I would really like someone show me an alternative way to enjoy the easiness of using modules with a possibility of using widgets. Some of you say to use name-spaced classed for this, or maybe there's another way.

Does anyone know a good example of such a solution which I can read and try out for myself? I would much appreciate a nudge in the right direction.

Thanks in advance!

Roger
Libraries
The solution I implemented in Sprint is part of the Themer system, but could be taken out and used on it's own with a little modification. It's modeled after ModX's style somewhat. In this you pass a string that contains the class/method name as well as any number of key/value pairs. The system tries to find a namespaced class that matches and, if that doesn't work, assumes it's a standard Library so it will try to load that up. The parameters are broken apart and sent as an array to the callable method so that you can implement a form of named parameter in PHP, and doesn't require any specific order to the params.


- View Callables Docs
- View Callables Source

I was thinking this weekend that I should split this out into it's own package and will probably do that later this week.
Does the module depend on another module?

If yes - you're doing it wrong.
If it can work on its own - you're all fine.
Inspired by this post, I took a couple of hours tonight to get started with a useable "widget" system called Bays. It's very simple, and doesn't require any formal MVC triads, like CakePHP's View Cells. Instead, you tell it what class to load and method to run, as well as provide some named parameters that are passed to it, and it expects the rendered HTML to be returned to it.

It can be used in a very simple state right now, though there are 2 additional things for me to add to it:

1. Allow framework-specific solutions for finding classes when other autoloading doesn't work. I want to do this library in a framework-agnostic way, so this will require a small class passed to it for CodeIgniter-specific library loading.
2. Caching. Again, this will be done in a framework-agnostic way.

I hope to get both of those items up and running in the next few days.

Hope this helps out, and let me know if you have any questions!
Everything with HMVC (and modularization in general) tends to come down to what Narf said. If your module works on its own, you're fine. If your module requires another module in order to work properly, then something's wrong (I'm guilty of this myself in some of my older code).

If you do have a dependency on another module, but can't merge the dependent modules for some reason, they need to work properly without the other module(s). What this means depends on what the modules are doing for one another, but, in the end, it comes down to either failing gracefully or providing another means of fulfilling the request.
(05-27-2015, 08:24 AM)mwhitney Wrote: [ -> ]Everything with HMVC (and modularization in general) tends to come down to what Narf said. If your module works on its own, you're fine. If your module requires another module in order to work properly, then something's wrong (I'm guilty of this myself in some of my older code).

If you do have a dependency on another module, but can't merge the dependent modules for some reason, they need to work properly without the other module(s). What this means depends on what the modules are doing for one another, but, in the end, it comes down to either failing gracefully or providing another means of fulfilling the request.

I am not understanding this. If you have an Auth Module, most likely every module in your app might require it.
Are you talking controller to controller calls or a view calling different controllers?

I really do not understand the correct way to use HMVC and would love to see a tutorial.
And a 1.0 Beta has been released for Bays. This is the last I'll talk about it here, but it does have its own page in the Addons section now: the Bays Addon page.
(05-27-2015, 12:18 PM)frocco Wrote: [ -> ]I am not understanding this. If you have an Auth Module, most likely every module in your app might require it.
Are you talking controller to controller calls or a view calling different controllers?

I really do not understand the correct way to use HMVC and would love to see a tutorial.

I think the problem here is that a couple of terms are getting mixed up: packages and modules. CodeIgniter supports packages out of the box, unlike modules - which is just a term people use for packages under one of the two HMVC systems, really.

Taking your Auth Module as an example:

- The package would provide libraries, config files, etc that would implement the underlying guts of the authentication system. This is perfectly valid and a great use for packages. This is also a fine use for HMVC "modules", since you would be using it like a package of libraries and models.
- The module version could theoretically also have a controller that provides the login, forgot password, etc. In this case, all of this functionality should be contained within the module. It should not reach into other modules for anything.

There's basically 2 uses of HMVC, then:

the first that is a collection of shared code that focuses on a fairly narrow topic (like Auth). This stuff is specifically there to be used by other code and can be thought of exactly how CodeIgniter's packages is used.

The second case is more like a CMS' full-blown module. In these cases, it should all be self-contained. If you think of a Blog module, it would provide code to display the posts, create new posts, etc. All of its activity is based around the blog and there it should never reach into other modules (unless it's a "package" with shared libraries), and other modules should reach into it.

And that is where the original question comes into play: if modules are supposed to be clean and separated from each other, how can we easily display that information in other places where controllers outside of this module are running? In WireDesignz' HMVC solution, you can call Modules::run() to call a controller from another module and get some content back. This is a bad thing in CodeIgniter's case, because it wasn't designed to work that way and can cause problems with multiple instance of the CI singleton in play, confusing things horribly.

The best solution is to create a library that you can load from other controllers (think of it as a package here) and things work as they should.

Hopefully this makes sense. I'm not 100% sure it does. The waters are pretty muddy, depending on the exact use. Smile
(05-27-2015, 10:29 PM)kilishan Wrote: [ -> ]
(05-27-2015, 12:18 PM)frocco Wrote: [ -> ]I am not understanding this. If you have an Auth Module, most likely every module in your app might require it.
Are you talking controller to controller calls or a view calling different controllers?

I really do not understand the correct way to use HMVC and would love to see a tutorial.

Yes, that makes sense to me. I have seen other HMVC tutorials where a view runs a module method to render a checkout form.
If I understand you correctly, HMVC should not be used then in favor of just creating libaries.
Pages: 1 2 3 4