HMVC is more like the current Widgets. You could e.g. have one MVC call for a blog-entry and in that call, another MVC call for the comment list of that blog-entry. All encapsulated in its own Controller, Models and Views with their own responsibilities...

Most probably no:
- There are no real advantages over current architecture… well maybe there are for some cases when you need a widget to be self-contained with it's own actions and URLs.
- It will add complexity. A lot of complexity.
- It will possibly slows things down for cascade file system and stuff.

It would be a good idea if it was a distributed hierarchy, i.e. a cloud, but I don't think it's such a good idea..
After all it was in PAC upon which MVC is based/derived.

You could make something even better by creating either modules with REST or SOAP interfaces/services or separate applications (which could be run on the same or different servers) which would scale even better I think.

Luckily, Yii has web services and REST built right into it, so it should be more straight forward than the Kohana code in that article.

Maybe I did not got the idea of HMVC clear, but for me it looks like it is presented in Yii by CController's forward() method - it allows to run another route without making new HTTP request.

What is missing - is that if I need to capture output I should explicitly use output buffers and if I need to pass GET parameters to the route I call then I also should do this explicitly, something like this:

I'm new to Yii and have not dealt with widgets or modules yet as I am getting my first experience through the Agile web dev with Yii book and am just now on chapter 8.

I want to ask basically the same question but include my understanding based on the Codeigniter implementation. It appears that this same functionality is just not being called hmvc in Yii but to help clarify it here's how I have used the hmvc extension in codeigniter.

In Codeigniter

Top of the hierarchy:
application/controller/site.php
application/model/site.php
application/view/site.php

Assuming the default framework has been modified to include the hmvc extension,
the login module can simply be copied from one application to another
and work out of the box because it is fully self contained.

The user can get to the login module by either of the twohttp://localhost/site/login (assuming the login method of site controller loads the login module)
or byhttp://localhost/login (due to the way the hmvc checks the modules folder and autoloads the module).

The main site controller can send/recieve data to and from the login module and
the login module can send/recieve data to and from the main site controller.

To my understanding the purpose of this is so the login module can include
functionality or views from the main site and visa versa.

The login module can be included in the main site view as a sidebar widget. So if you created
a self contained calendar module you could have the main site view show the calendar as a sidebar widget.

So the question for me is, can this level of extendability, module reuse, and control
be accomplished with modules or widgets in Yii? Is it really just a matter of different terminology for the same thing?

HMVC (Hierarchial Model View Controller) and PAC (Presentation-Abstraction-Control) were both designed to solve the same architectural design problem but were implemented using different solutions. PAC is documented in the Gang of Four book and the author's papers. HMVC was documented in the original article appearing in JavaWorld. The principal designer of HMVC is in prison for attempting to hire someone to kill his wife, thus the designer never fully completed the Java framework proposed in the JavaWorld article. However, several JAVA implementations of HMVC existed for a while. A few of these are on SourceForge. From a developer standpoint, MVC frameworks gained much more popularity and won the framework wars of that time period. I have not used the Kohana implementation in its current revision level, but I have used the CodeIgniter solution from wiredesignz. Regardless of whether or not they behave like true HMVC, they both attempt to solve the same problem using author-developed solutions as does Yii.

A true implementation of HMVC uses the Chain of Responsibility behavior design pattern. The only true implementation of HMVC for PHP that I am aware of is the Claw framework originated on Tigris and abandoned by the author years ago. There are two versions on Tigris--the downloadable version and the version in SVN. The SVN version includes more improvements. As I understand it, the original idea for HMVC was to create an application using a hierarchial structure of MVC triads from a top triad (the application) through any number of intermediate triads and then the lowest level triad (usually a standalone widget in MVC form). The lowest level with the lowest triads in communication with their parent triads using the Publish and Subscribe design pattern (Observer pattern). Events were triggered at the widget level triad (e.g., a button press or other HTML element activity triggered and event which was observed by the ascendent triads).

PAC uses the Mediator behavioral design pattern rather than the Chain of Responsibility pattern. The triad are composed of three agents. The Presentation agent is similar to a View in purpose. The View agent cannot access the Abstraction agent directly where this is allowed in HMVC. The Abstraction agent contains no actual model code and sends requests to a central storage solution which passes the queries through the Control agent enroute to the View. The Control is somewhat similar to a MVC controller but has more responsibilities and those responsibilities are enforced more strictly than MVC.

I do not post much although I visit here a lot, but have been using and learning Yii for about 20 months. Of the frameworks I have used over the past 10+ years, I consider Yii to be the best solution for my needs and for me a far better and elegant solution than PAC, HMVC and other architectural patterns. It should be possible to mimic a true HMVC architecture down to the widget level using any number of nested modules with Yii in combination with the Observer pattern but using Yii IMHO as it was intended is a better, simpler, and more versatile solution. Once you get over the initial learning curve and build a modular application foundation for building projects with reusable modules and portlets, you can use that code as a base for starting new projects and save a lot of time by doing so.

Most probably no:
- There are no real advantages over current architecture… well maybe there are for some cases when you need a widget to be self-contained with it's own actions and URLs.
- It will add complexity. A lot of complexity.
- It will possibly slows things down for cascade file system and stuff.

Excellent post, almost an article in it's own right.
This should exist elsewhere for the edification of the masses, as it seems a shame to leave it buried within a forum thread.

mmx, on 23 January 2012 - 03:17 PM, said:

HMVC (Hierarchial Model View Controller) and PAC (Presentation-Abstraction-Control) were both designed to solve the same architectural design problem but were implemented using different solutions. PAC is documented in the Gang of Four book and the author's papers. HMVC was documented in the original article appearing in JavaWorld. The principal designer of HMVC is in prison for attempting to hire someone to kill his wife, thus the designer never fully completed the Java framework proposed in the JavaWorld article. However, several JAVA implementations of HMVC existed for a while. A few of these are on SourceForge. From a developer standpoint, MVC frameworks gained much more popularity and won the framework wars of that time period. I have not used the Kohana implementation in its current revision level, but I have used the CodeIgniter solution from wiredesignz. Regardless of whether or not they behave like true HMVC, they both attempt to solve the same problem using author-developed solutions as does Yii.

A true implementation of HMVC uses the Chain of Responsibility behavior design pattern. The only true implementation of HMVC for PHP that I am aware of is the Claw framework originated on Tigris and abandoned by the author years ago. There are two versions on Tigris--the downloadable version and the version in SVN. The SVN version includes more improvements. As I understand it, the original idea for HMVC was to create an application using a hierarchial structure of MVC triads from a top triad (the application) through any number of intermediate triads and then the lowest level triad (usually a standalone widget in MVC form). The lowest level with the lowest triads in communication with their parent triads using the Publish and Subscribe design pattern (Observer pattern). Events were triggered at the widget level triad (e.g., a button press or other HTML element activity triggered and event which was observed by the ascendent triads).

PAC uses the Mediator behavioral design pattern rather than the Chain of Responsibility pattern. The triad are composed of three agents. The Presentation agent is similar to a View in purpose. The View agent cannot access the Abstraction agent directly where this is allowed in HMVC. The Abstraction agent contains no actual model code and sends requests to a central storage solution which passes the queries through the Control agent enroute to the View. The Control is somewhat similar to a MVC controller but has more responsibilities and those responsibilities are enforced more strictly than MVC.

I do not post much although I visit here a lot, but have been using and learning Yii for about 20 months. Of the frameworks I have used over the past 10+ years, I consider Yii to be the best solution for my needs and for me a far better and elegant solution than PAC, HMVC and other architectural patterns. It should be possible to mimic a true HMVC architecture down to the widget level using any number of nested modules with Yii in combination with the Observer pattern but using Yii IMHO as it was intended is a better, simpler, and more versatile solution. Once you get over the initial learning curve and build a modular application foundation for building projects with reusable modules and portlets, you can use that code as a base for starting new projects and save a lot of time by doing so.

Most probably no:
- There are no real advantages over current architecture… well maybe there are for some cases when you need a widget to be self-contained with it's own actions and URLs.
- It will add complexity. A lot of complexity.
- It will possibly slows things down for cascade file system and stuff.

HMVC doesn't need any connection with cascading file systems. They are two separate things.