[Volli]

Will we see a HMVC-Feature in Yii2.0?

http://techportal.ib...ions-with-hmvc/

[jacmoe]

Yii already has modules.
Am I missing something? What does HMVC offer that modules doesn't feature?

[Volli]

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...

[imehesz]

hello,

that sounds like modules to me, too ...
http://www.yiiframew...n/basics.module

you can call modules from other modules if you want to ...

--iM

[samdark]

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.

[Volli]

@imehesz You can get the reponse of a MVC-request and a module-response within one request? Did you read the article of the first comment?

@samdark it enables you to reuse code from other controllers without duplicating it, but yes , it could slow down the application if you use it

[jacmoe]

I read the example and noticed that it uses modules.

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.

It doesn't belong in Yii, however. IMO.

[seb]

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:

action forwardAction() 
{
    $temp = $_GET;
    $_GET = array('param1'=>'xxx', 'param2'=>'yyy');

    ob_start();
    //second parameter = false - do not exit
    $this->forward('target/action', false);
    $response = ob_get_clean();

    ...
    echo $response;
} 

[gazbond]

I have been looking into HMVC here is another article: http://paranoid-engi...controller.html
What I find interesting:

Controllers:
List->default
List->category
List->search
Product->default
Product->reviews
etc.

Urls:
http://www.shop.com/list/
http://www.shop.com/list/category
http://www.shop.com/list/category/4
http://www.shop.com/list/search/query.hammer
http://www.shop.com/list/category/4/product/2524
http://www.shop.com/list/search/query.hammer/product/2524
http://www.shop.com/product/2524
http://www.shop.com/list/search/query.hammer/page.4/product/2524
http://www.shop.com/list/category/25/page.42/product/11945/reviews
http://www.shop.com/list/search/query.big+fork/sort.price/order.asc/page.18/product/114/review
http://www.shop.com/product/1545/reviews

Hierarchical UI's need to be able to pass data down the hierarchy. I played around with this a while back using Zend if anyone is interested?

[gazbond]

^^ my experiment with Zend and hierarchical UI's.

Attached File(s)

•  nuui-template.zip (108.13K)
  Number of downloads: 28

[limitless]

for me, all the functionality i need is already included in modules...

[iansane]

Hi,

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


Login module
application/modules/login/controllers/login.php
application/modules/login/models/login.php
application/modules/login/views/login.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 two
http://localhost/site/login (assuming the login method of site controller loads the login module)
or by
http://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?

Thanks

[samdark]

Almost. In Yii modules and widgets are separated.

[erkasoft]

samdark, on 09 November 2011 - 06:30 PM, said:

Almost. In Yii modules and widgets are separated.

Indeed, I used Kohana before Yii. Kohana use HMVC. I don't see any difference for HVMC.

[mmx]

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.

[Cherif]

samdark, on 14 June 2011 - 03:28 PM, said:

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.

Hi alex,

What you mean here? Did you talk about widget as action provider? like in this wiki:
How to use a Widget as an Action Provider

[samdark]

Yes. The case with many non-AJAX interactive widgets on a single page.

[Cherif]

samdark, on 17 December 2012 - 04:03 AM, said:

Yes. The case with many non-AJAX interactive widgets on a single page.

Thank you alex

[intel352]

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.

[phazei]

samdark, on 14 June 2011 - 03:28 PM, said:

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.