Thread

After reading this article How to use Model-View-Controller which describes the original concepts of MVC in relation to Smalltalk-80, my understanding of the subject has become a bit clearer.

The idea of a single Controller doing everything (as used in CI and other frameworks) doesn’t fully meet the original design.

A single page (screen or output) is constructed by using multiple MVC triads (modules aka partials) where the Controllers communicate with each other using the Observer pattern (xwero)

For me this implies Modular Extensions is more MVC than HMVC. (Now if I could get Khaos events working with modules that would be something)

Anyway if you are interested have a read for yourselves and post your thoughts.

For me this implies Modular Extensions is more MVC than HMVC. (Now if I could get Khaos events working with modules that would be something)

Basically, I agree with everything in your post and believe you are on the right track.

HMVC is an independent architectural design pattern in itself as are MVC, PAC and other architectural design patterns. Modular Extensions might not be HMVC, but you’re simulating the concept within the MVC architecture. Architectural design patterns are composed of many other design patterns. The combination of those patterns is used to differentiate between the various architectural patterns. For example, HMVC and PAC are similar in intent (nested triads (agents) arranged in one or more hierarchies), but HMVC is based on the Chain of Responsibility pattern and PAC is based on the Mediator pattern (which can be very Observer-like in some implementations).

Khaos Events Manager was based on some ideas from Joomla 1.0.x and 1.5.x. The Joomla 1.5.x API docs for JEvent and the Plugin development docs should be helpful for getting a better idea of the overall concept. The API is actually a bit more powerful than what the Event Manager thread suggests. In Joomla, it’s possible to trigger events from something like a content module, allowing things like modules and partials to be embedded in content. You can probably download a copy of Joomla, then compare the two code implementions in relation to the Joomla docs. Plugins are also the basis for Joomla’s generic authentication API which allows separate plugins to be created for different authentication schemes. It’s also possible to have different flavors of plugins which are stored in separate directory structures based on the kind of events that are triggered.

Basically, Khaos Event Manager introduces a second more powerful plugin concept to CI, thus the reasoning for the khaos directory.

===================
Maybe another Joomla 1.5.x class to investigate is JDocument which behaves like a special kind of controller for master views (templates), allowing predefined template regions like left or right to be populated with partials using a database query. The template regions are registered in a table. For reference, Joomla partials are (called modules and a CI module is called a component. Just about anything that can be installed to extend Joomla is registered in database tables, allowing the various Joomla classes to query for component, module, plugin, template, and language information, including redirect paths in the case of components (which are generally view specific in the sense that all views managed by a controller have a registered redirect path). It might be possible to transform your View Object into more of a document manager for templates in a fashion somewhat similar to JDocument, but using CI approaches.

The distinction between a template region and a partial in the Joomla sense is that a region can be defined in a database table and those regions are generally empty html containers (an empty view fragment). These empty regions are populated with partials using a database query. Thus, selections of partials can be assigned to a region and separate templates can be assigned to modules.

A while back, Pygon started an interesting thread about CI not being true to the MVC architectural pattern. Some of his ideas about view controllers might be helpful.

There is no point in arguing patterns here, but CI is more “rails MVC” than “real MVC.”  The approach used is really just your basic three tier architecture (presentation, logic, data).  It isn’t really MVC, but it works.  Also, the RoR naming conventions have spread through the community, so devs seem to have a mutually understanding when using a term in reference to an RoR like framework.