Calling a controller from another controller

[eluser]wiredesignz[/eluser]
[quote author="Colin Williams" date="1223693283"]Just to be clear, I'm not claiming controllers serving other controllers is bad MVC. It's just not CodeIgniter MVC.

Colin’s attempt was meant to shed light on how CI accomplishes things

See. Randy got the point.[/quote]

Don't you get tired of the Colin and Randy show?

@randy, nobody has to prove anything. Whenever you pass control to a library you effectively have controller to controller communication. Just because its called a `something else` doesn't change the fact it's performing a controller function.

[eluser]Colin Williams[/eluser]
Well, wired, the difference is that methods of a Library aren't mapped to a URI by convention, as Controller methods are in CI. And I don't remember suggesting that the OP use a Library instead. We weren't even sure what Mr Lazy was trying to achieve at first. He solved it by redirecting, or in other words, by invoking the proper controller method via a URI, which is how CI works.

[eluser]wiredesignz[/eluser]
Every web application must map an action to a URL somehow Colin. CI is not unique here.

I am referring to management of parts of a single output from multiple MVC triads communicating via events or chain of responsibility.

[eluser]Colin Williams[/eluser]

I am referring to management of parts of a single output from multiple MVC triads communicating via events or chain of responsibility.

So, you're talking about a different thing entirely. And I think controllers serving a "piece" of final output is inevitable in that scheme. And I agree that if you used a Library to do this, like you said, it's still a Controller, just by a different name. My point is that CI is, unfortunately, not setup by default to work in this way, which is why your ME-HMVC solution (or Wick) is necessary.

[eluser]Randy Casburn[/eluser]
[quote author="wiredesignz" date="1223695949"]
@randy, nobody has to prove anything. [/quote]

I take exception to your use of exacting terminology when it comes to a very fluid conceptual idea.

CI works natively the way Colin says. There is no Randy and Colin show here, there is a CI reality. Colin simply stated that truth.

There is no doubt that it is pinned to the wall with the confines of your implementation. Thats because you get to define things the way you see fit in your world. The HMVC contribution is your world. You definitions are definitely good there.

So state that your definitions are relevant to your implementation within the confines of HMVC for CI.

That way community contributions that supplement CI and the definitions that go along with those contributions won't cloud the CI reality.

It's that simple.

Randy

[eluser]wiredesignz[/eluser]
Every web application works the way Colin describes. duh!

Most frameworks allow the use of multiple MVC triads in a single request/response, and there is no reason no to do this in CI regardless of some ridiculous idea you may have that you are being faithful to the CI implementation of MVC by not doing so.

What you take exception to is actually irrelevant Randy.

It's what works for each of us that counts.

[eluser]Randy Casburn[/eluser]
"True MVC" is exactly equal to this or exactly equal to that as you state above is ridiculous and irrelevant wired.

But let's leave this at "once again...Randy and wiredesignz disagree".

Randy

[eluser]wiredesignz[/eluser]
[quote author="Randy Casburn" date="1223704796"]But let's leave this at "once again...Randy and wiredesignz disagree".[/quote]

Let's not do that.

To use the MVC paradigm effectively you must understand the division of labor within the MVC triad. You also must understand how the three parts of the triad communicate with each other and with other active views and controllers...

Communication Between Controllers

The primary organizing principle which makes this trick possible is that the active controllers for each project form a hierarchical tree.

http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html

[eluser]Colin Williams[/eluser]
Newbies need to understand how CI works out of the box, and they need to know how to use contributions to make it work the way they envision. When Randy and I say "this is how CI works" we aren't saying "this is the way you must do it if you use CI."

You and Randy are going back and forth about the "true MVC" declaration, and I think what Randy and I want newer CI users to understand is that there is a "CI MVC" and a "CI + Modular Extensions (H)MVC" and a "Ruby on Rails MVC" and a "Zend Framework MVC" and on and on and on. Aspects of each are similar and aspects of each are different, but claiming either is "true" isn't very constructive to newcomers.

Edit:

And, wired, I think what you are doing is trying to enlighten users to a specific (by no means "exotic") way of understanding MVC that you believe will serve users the most, and I take no issue with that.

[eluser]wiredesignz[/eluser]
Get a grip Colin, don't get so upset.

There is only one MVC design pattern, all of the frameworks use it, some enforce more strict usage of MVC, CI is clearly a loose implementation.

What newbies to CI need to know will come from their own experience with it, Certainly not from Randy's obtuse descriptions based on his limited understanding, and not from you bashing them over the head with your ideas either.