Is it possible to load a controller?

[eluser]Rick Jolly[/eluser]
For anyone against the idea of HMVC, I want to show a practical example. A shopping cart:

1) The typical method couples the controller to the view:

Code:

// controller
$data['cart'] = $this->load->view('cart',$cart_data,true);
$this->load->view('page',$data);
// view
<?=$cart;?>

Disadvantage: The controller is coupled to the view. There is an unnecessary dependency leading to slightly lower productivity and more importantly, potential maintenance problems.

2) HMVC psuedocode:

Code:

// view
<?=module('cart');?>

Advantage: No dependency. The module is responsible for the data and the display. Nested MVC triads plug-and-play. That is encapsulation and modularity. Isn't that what we strive for??

[eluser]Colin Williams[/eluser]

Nested MVC triads plug-and-play

They plug, sure, but they don't exactly plug-and-play. ME's implementation of modular design requires that modules be invoked on demand, either from a controller or a view. So, again, they plug, but you still have to wade through your code and play them as needed. There are more elegant modular designs in which a module responds to events or aspects of the application and performs their intended function. In this model, it is the burden of the module to do what it should when it should, and not the burden of the central system to tell it to do so. The ME approach is not wrong, I just think there's an even better way.

[eluser]Randy Casburn[/eluser]
@Rick -- Is this really true? Your post is slightly misleading. Isn't the dependency just shifted into the construction of the module? At some point it would seem you still must link the data to some form of a template and output that in the form of a view of some type. Doesn't that create a dependency (in the module)?

wiredesignz work has allowed folks to compartmentalize their thoughts, code, views, ideas, artifacts, etc. into groupings that make sense to them. The dependencies are rational then because they become reusable units or groupings of organized things that make sense. His "implementation" in the form of code took a distinct route that has been adopted by some as one approach that makes sense. Not everyone will agree that is the best or most appropriate approach, but it is solid and meets the goals of those that seek to do what this paragraph says.

Do you have to implement so much to do "is it possible to load a controller?" as the OP requested? No. You don't have to implement HMVC to dynamically implement controller functionality from within CI.

@OP -- This is very, very simple to do if you can open your mind beyond PHP+MySQL+Apache, are not hell bent on believing a design pattern was ordained by a supreme being and must be followed or you'll be struck down by lightning, and will accept that you don't have to hack CI or write 5000 lines of PHP to accomplish this.

Randy

[eluser]beemr[/eluser]
[quote author="Randy Casburn" date="1216690382"]At some point it would seem you still must link the data to some form of a template and output that in the form of a view of some type. Doesn't that create a dependency (in the module)?[/quote]

That's about where the H falls off of most HMVC attempts in PHP and other environments. No matter how OOP & HMVC your backend is, your final output ends up as linear XHTML. There are frameworks such as Seaside for Smalltalk that purport to offer true HMVC, but, as ever, there are tradeoffs. Everybody's code must produce stateless, linear HTTP and therein lies the rub.

The incompleteness of the solution is what made me to decide to stick to libraries.

[eluser]Michael;[/eluser]
[quote author="Aquillyne" date="1216679306"]On a completely separate note, this sounds very interesting. Care to explain more?[/quote]

What would you like me to expand upon? I just looked and it's actually 27 lines of code, 34 when you add in line spacing. The code is kept to a minimum by a couple of libraries that I created. What I'd like to be able to do though is move things like /config, /errors, and /hooks to the system folder so that I do not have to repeat it for every application. I guess that's my own personal pipe dream; the application folder would have "model", "view", and "controller" folders and that is it unless you *NEED* something more.

It's a basic controller that merely retrieves a piece of content from the database either by nid ( node id ) or path_alias ( built into the node table ) based on picking apart the url; for example:

http://www.example.com/index.php/node/001 => would return node id 1, the home page.
http://www.example.com/index.php/node/home => would also return node id 1, which is identified in the node table as "home".

If the node you are looking for does not exist it returns node id '0' which is nothing more than a "Page not found" notice.

[eluser]Rick Jolly[/eluser]
[quote author="Randy Casburn" date="1216690382"]@Rick -- Is this really true? Your post is slightly misleading. Isn't the dependency just shifted into the construction of the module? At some point it would seem you still must link the data to some form of a template and output that in the form of a view of some type. Doesn't that create a dependency (in the module)?
[/quote]
A one-to-one dependency. The view won't work without the module and vice-versa. Complete separation broken down into a single-purpose unit.

The alternative leads to more dependencies and repetition. Repetition leads to productivity and maintenance problems. DRY.

Maybe an example will help. Let's say you have a cart on 5 pages:

HMVC: 5 views loading module, 1 cart module, 1 cart view = 7 files
Alternative: 5 views with cart placeholder, 5 controllers, 1 cart library, 1 cart view = 12 files and more dependencies.

[eluser]beemr[/eluser]
[quote author="Rick Jolly" date="1216694988"]HMVC: 5 views loading module, 1 cart module, 1 cart view = 7 files
Alternative: 5 views with cart placeholder, 5 controllers, 1 cart library, 1 cart view = 12 files and more dependencies.[/quote]

You could also use libraries as a separate MVC like so:
5 views loading library, 1 cart library, 1 cart view = also 7 files

[eluser]Rick Jolly[/eluser]
[quote author="beemr" date="1216695698"][quote author="Rick Jolly" date="1216694988"]HMVC: 5 views loading module, 1 cart module, 1 cart view = 7 files
Alternative: 5 views with cart placeholder, 5 controllers, 1 cart library, 1 cart view = 12 files and more dependencies.[/quote]

You could also use libraries as a separate MVC like so:
5 views loading library, 1 cart library, 1 cart view = also 7 files[/quote]
Exactly. It's the same thing. That's HMVC. The library is the controller in that case, and it is the intermediary between the cart view and (optionally) a cart model.

[eluser]Michael;[/eluser]
[quote author="Rick Jolly" date="1216694988"]
Maybe an example will help. Let's say you have a cart on 5 pages:

HMVC: 5 views loading module, 1 cart module, 1 cart view = 7 files
Alternative: 5 views with cart placeholder, 5 controllers, 1 cart library, 1 cart view = 12 files and more dependencies.[/quote]

That is absolutely incorrect:

HMVC still loads the same 12 files that the core MVC would load ( and I think that 12 files is high ) and then in addition you must load ME which in turn fundamentally alters the flow of the framework, thus creating more over head. There is a reason CI is the fastest framework out there.

[eluser]Rick Jolly[/eluser]
[quote author="Michael." date="1216695971"][quote author="Rick Jolly" date="1216694988"]
Maybe an example will help. Let's say you have a cart on 5 pages:

HMVC: 5 views loading module, 1 cart module, 1 cart view = 7 files
Alternative: 5 views with cart placeholder, 5 controllers, 1 cart library, 1 cart view = 12 files and more dependencies.[/quote]

That is absolutely incorrect:

HMVC still loads the same 12 files that the core MVC would load ( and I think that 12 files is high ) and then in addition you must load ME which in turn fundamentally alters the flow of the framework, thus creating more over head. There is a reason CI is the fastest framework out there.[/quote]
No, 7 files. Reread the post. I'm not talking about ME (although it's excellent) which is ONE implementation of HMVC, I'm refering to the general concept. Which as beemr pointed out, can be accomplished with a library. LESS files, LESS overhead.

Edit:
Ok, you're correct regarding 12 files. I was thinking 7 files dependent on the cart as opposed to 12. But, yes 12 files total.

I see what you are saying. You're concerned with overhead. I'm concerned about maintainability and productivity. If you load the library from the view (or better to use a view helper which loads the library) then the amount of code and performance is similar either way.