HMVC in ZF2

[Marten Lienen]

Hello,
first I want to say that I probably dont know the whole current state of affairs
as far as HMVC is concerned since I just recently subscribed to this list. Am
I right that ZF2 is going to feature HMVC? Is there a draft implementation? I
didn't find any. If there is none I will post my draft implementation tomorrow
for discussion. If there is one I would like to view it and share my thoughts.

Best regards,
Marten Lienen

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[weierophinney]

-- Marten Lienen <[hidden email]> wrote
(on Monday, 16 May 2011, 01:51 AM +0200):
> first I want to say that I probably dont know the whole current state
> of affairs as far as HMVC is concerned since I just recently
> subscribed to this list. Am I right that ZF2 is going to feature HMVC?
> Is there a draft implementation? I didn't find any. If there is none I
> will post my draft implementation tomorrow for discussion. If there is
> one I would like to view it and share my thoughts.

It's a consideration for ZF2, but nothing has been decided in that
direction yet. The primary issue we have is complexity of
implementation. I've reviewed implementations in other frameworks and
languages, and there are quite a few pieces that can lead to difficulty
in either (a) maintenance, or (b) documentation and education.
Additionally, we may not need a full-blown HMVC solution depending on
(c) what we expect controllers to return (e.g., they may simply return
values or "view models"), or (d) when the view is rendered (if rendered
just before returning the response, we may not need hierarchical views,
as everything can be pre-determined).


--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Александр Шелковский]

Hello,

wouldn't it be more problems if in 2.0 we have not HMVC solution, but in 2.1
we will have HMVC? It will require to add more documentation, backward
capability, and confuse developers much more. Also I think it would be more
time consuming for the Zend team itself, since it have to develop 2 versions
of the MVC approach. I think we need choose one way to do it and follow it
under all 2.* tree. On the other hand I am agree to wait until we have good
MVC solution in 2.0.

Regards, Alex.

[weierophinney]

-- Александр Шелковский <[hidden email]> wrote
(on Monday, 16 May 2011, 10:55 PM +0700):
> wouldn't it be more problems if in 2.0 we have not HMVC solution, but in 2.1
> we will have HMVC? It will require to add more documentation, backward
> capability, and confuse developers much more. Also I think it would be more
> time consuming for the Zend team itself, since it have to develop 2 versions
> of the MVC approach. I think we need choose one way to do it and follow it
> under all 2.* tree. On the other hand I am agree to wait until we have good
> MVC solution in 2.0.

We may be able to make the MVC layer flexibile enough that an HMVC
approach could be added as a layer on top of it.

That said, I'd like a discussion on what HMVC offers developers, and
what use cases it is particularly suited for. I mainly hear folks say,
"please do an HMVC solution," without stating why or what it provides
them. While I've studied several such systems, I personally found them
to be fairly complex to understand and code for -- and as such, would
like some discussion of the uses cases it solves and how and why it's
simpler than other alternatives.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Benjamin Dubois]

Hi !

I read different articles lately about this subject, and the common goal seems to be splitting a webapp into several independent layers sharing the same request (as far as I understand), in order to ease scalability (and provide a better separation of layers via independent applications).

If this really is the goal of this design, I see several potential issues :

- In my mind, Hierarchical architecture does not fit well (at all) with horizontal scalability : if there is a "root" controller managing all requests, it becomes a SPOF for the entire stack of applications. This can be avoided with load balancing on the network level, but in that case, will the root controller provide any added value ?

- If the controllers communicate between each other using the http protocol, then an additional PHP parsing of the request is just an overload. If PHP is used for communication between controllers, that means that if I need to use another language for one of my MVC triads, I will have to rewrite my entire stack.

I may be completely out of the subject(sorry if I am), but if I am not, I think that Hmvc could lead to a more complex MVC layer into the framework, for very little or no real gain, vs existing (less integrated, but probably more efficient) solutions...

--
Regards,
Benjamin Dubois


Le 16 mai 2011 à 21:25, Matthew Weier O'Phinney a écrit :

> -- Александр Шелковский <[hidden email]> wrote
> (on Monday, 16 May 2011, 10:55 PM +0700):
>> wouldn't it be more problems if in 2.0 we have not HMVC solution, but in 2.1
>> we will have HMVC? It will require to add more documentation, backward
>> capability, and confuse developers much more. Also I think it would be more
>> time consuming for the Zend team itself, since it have to develop 2 versions
>> of the MVC approach. I think we need choose one way to do it and follow it
>> under all 2.* tree. On the other hand I am agree to wait until we have good
>> MVC solution in 2.0.
>
> We may be able to make the MVC layer flexibile enough that an HMVC
> approach could be added as a layer on top of it.
>
> That said, I'd like a discussion on what HMVC offers developers, and
> what use cases it is particularly suited for. I mainly hear folks say,
> "please do an HMVC solution," without stating why or what it provides
> them. While I've studied several such systems, I personally found them
> to be fairly complex to understand and code for -- and as such, would
> like some discussion of the uses cases it solves and how and why it's
> simpler than other alternatives.
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [hidden email]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Wil Moore III]

>
> - In my mind, Hierarchical architecture does not fit well (at all) with
> horizontal scalability : if there is a "root" controller managing all
> requests, it becomes a SPOF for the entire stack of applications. This can
> be avoided with load balancing on the network level, but in that case, will
> the root controller provide any added value ?


I agree Benjamin, also, my biggest concern with the HMVC approach (at least
the way I've been reading about it in the more recent frameworks), is this
in-request sub-request. Seems pretty hacky to me. There are far greater
tools available for distributing load. Not to mention, I don't see how this
pattern is used within a console-based application where you are forking
multiple processes off as part of a job queuing system.

Also, as a side-note, I'm noticing a pattern of requests for ZF2
(specifically the MVC portion) to do a ton of things on behalf of the
developer at the framework level that should be done at the application
level. I want to be careful not to discourage people from requesting what
they feel they need; however, I would at least like to caution that this is
something to consider when making requests.

[Enrico Zimuel-2]

>
> I agree Benjamin, also, my biggest concern with the HMVC approach (at least
> the way I've been reading about it in the more recent frameworks), is this
> in-request sub-request. Seems pretty hacky to me. There are far greater
> tools available for distributing load. Not to mention, I don't see how this
> pattern is used within a console-based application where you are forking
> multiple processes off as part of a job queuing system.
>

This is the defintion of HMVC from the original article appears in the
JavaWorld Magazine in 2000 (http://bit.ly/8Scr0h).

"The HMVC pattern decomposes the client tier into a hierarchy of
parent-child MVC layers. The repetitive application of this pattern
allows for a structured client-tier architecture."

A lot of PHP frameworks support the HMVC, for instance:

Fluency, http://code.google.com/p/fluency/
Kohana, http://kohanaframework.org/
Alloy, http://alloyframework.org/

But I found that they support HMVC differently from the original idea.
Basically they support a single request with different controllers in a
view, offering the possibility to reuse a subset of the MVC. But this is
not the original idea of HMVC where you should have isolated tiers of
MVC that communicate each other to manage different pieces of
application.

This page of the Alloy framework explains the implementation of HMVC:
http://alloyframework.org/manual/architecture/hierarchal-mvc/

I think if we consider HMVC just the possibility to manage a single
request with multiple controllers this is something that we already
support in ZF with the Action View Helper.

What do you think?


--
Enrico Zimuel
Senior PHP Engineer     | [hidden email]
Zend Framework Team     | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[keith Pope-4]

The action view helper is pretty ugly for this kind of thing. It would be better if you could route to more than one controller.

I am not tottaly sold on hmvc, if you want to distribute parts of your system messaging is probably going to give you more. Rabbitmq, zeromq etc using soa posibily cqrs is going to give you a more separation and scalability.

Thx keith

Enrico Zimuel <[hidden email]> wrote:

>
>>
>> I agree Benjamin, also, my biggest concern with the HMVC approach (at least
>> the way I've been reading about it in the more recent frameworks), is this
>> in-request sub-request. Seems pretty hacky to me. There are far greater
>> tools available for distributing load. Not to mention, I don't see how this
>> pattern is used within a console-based application where you are forking
>> multiple processes off as part of a job queuing system.
>>
>
>This is the defintion of HMVC from the original article appears in the
>JavaWorld Magazine in 2000 (http://bit.ly/8Scr0h).
>
>"The HMVC pattern decomposes the client tier into a hierarchy of
>parent-child MVC layers. The repetitive application of this pattern
>allows for a structured client-tier architecture."
>
>A lot of PHP frameworks support the HMVC, for instance:
>
>Fluency, http://code.google.com/p/fluency/
>Kohana, http://kohanaframework.org/
>Alloy, http://alloyframework.org/
>
>But I found that they support HMVC differently from the original idea.
>Basically they support a single request with different controllers in a
>view, offering the possibility to reuse a subset of the MVC. But this is
>not the original idea of HMVC where you should have isolated tiers of
>MVC that communicate each other to manage different pieces of
>application.
>
>This page of the Alloy framework explains the implementation of HMVC:
>http://alloyframework.org/manual/architecture/hierarchal-mvc/
>
>I think if we consider HMVC just the possibility to manage a single
>request with multiple controllers this is something that we already
>support in ZF with the Action View Helper.
>
>What do you think?
>
>
>--
>Enrico Zimuel
>Senior PHP Engineer     | [hidden email]
>Zend Framework Team     | http://framework.zend.com
>Zend Technologies Ltd.
>http://www.zend.com
>
>
>--
>List: [hidden email]
>Info: http://framework.zend.com/archives
>Unsubscribe: [hidden email]
>
>

[padraicb]

Hi all,

HMVC is basically implemented in PHP all the time. The frameworks claiming this
are building on two very familiar and old concepts:

1. Composing content via multiple dispatches to controllers within the same PHP
process.
2. Relying on their simplicity and lack of features to maintain reasonable
performance.

ZF1 could do the exact same thing from Day 1 so this means ZF is, oddly enough,
also a valid HMVC framework. The problem is we, Symfony, Lithium and any other
large framework have is that this approach simply does not perform
satisfactorily. Other frameworks claim HMVC purely on the basis that they are
light enough to reduce the performance penalty to the point where it's
acceptable. Larger frameworks just cannot compete on this same level - so we end
up using View Helpers (and similar such lightweight solutions) to do the same
thing with less code and significantly less processing.

In effect, HMVC is just a new buzzword being used by other frameworks for no
particular reason.

The interesting aspect of HMVC is splitting the processing across multiple
threads to increase performance (akin to asynchronous processing). Obviously,
PHP and Threads don't belong in the same sentence. We can, however, perform
asynchronous tasks using, as Keith notes, stuff like task and message queueing.
If we were talking about Ruby, a better example might be EventMachine.

So, HMVC? I don't see it as a ZF2 requirement. Though, keeping an open mind,
that is based on the limits imposed on us by MVC performance. I'm expecting ZF2
to hand Symfony's current marketing on the basis of its speed a serious blow ;).
ZF1 without the bells and whistles is already 12% faster than Symfony 2 based on
a thoroughly pointless benchmark (which is fun to run anyway :P).

Paddy

 Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team





________________________________
From: Keith Pope <[hidden email]>
To: [hidden email]
Sent: Tue, May 17, 2011 5:48:48 PM
Subject: Re: [zf-contributors] HMVC in ZF2

The action view helper is pretty ugly for this kind of thing. It would be better
if you could route to more than one controller.

I am not tottaly sold on hmvc, if you want to distribute parts of your system
messaging is probably going to give you more. Rabbitmq, zeromq etc using soa
posibily cqrs is going to give you a more separation and scalability.

Thx keith

Enrico Zimuel <[hidden email]> wrote:

>
>>
>> I agree Benjamin, also, my biggest concern with the HMVC approach (at least
>> the way I've been reading about it in the more recent frameworks), is this
>> in-request sub-request. Seems pretty hacky to me. There are far greater
>> tools available for distributing load. Not to mention, I don't see how this
>> pattern is used within a console-based application where you are forking
>> multiple processes off as part of a job queuing system.
>>
>
>This is the defintion of HMVC from the original article appears in the
>JavaWorld Magazine in 2000 (http://bit.ly/8Scr0h).
>
>"The HMVC pattern decomposes the client tier into a hierarchy of
>parent-child MVC layers. The repetitive application of this pattern
>allows for a structured client-tier architecture."
>
>A lot of PHP frameworks support the HMVC, for instance:
>
>Fluency, http://code.google.com/p/fluency/
>Kohana, http://kohanaframework.org/
>Alloy, http://alloyframework.org/
>
>But I found that they support HMVC differently from the original idea.
>Basically they support a single request with different controllers in a
>view, offering the possibility to reuse a subset of the MVC. But this is
>not the original idea of HMVC where you should have isolated tiers of
>MVC that communicate each other to manage different pieces of
>application.
>
>This page of the Alloy framework explains the implementation of HMVC:
>http://alloyframework.org/manual/architecture/hierarchal-mvc/
>
>I think if we consider HMVC just the possibility to manage a single
>request with multiple controllers this is something that we already
>support in ZF with the Action View Helper.
>
>What do you think?
>
>
>--
>Enrico Zimuel
>Senior PHP Engineer     | [hidden email]
>Zend Framework Team     | http://framework.zend.com
>Zend Technologies Ltd.
>http://www.zend.com
>
>
>--
>List: [hidden email]
>Info: http://framework.zend.com/archives
>Unsubscribe: [hidden email]
>
>

[keith Pope-4]

+1 for the pointless benchmarks, the performance marketed by various source is probably total premature optimization, in most situations no one will ever notice the performance difference between the frameworks. When you start to hit the barrier of MVC performance you then need soa, messaging, eventual consistancy etc none of which your standard framework will address, this type of performance barrier will in most cases require custom implementation. I think people forget why we use MVC, its for the maintainence not the performance. If we want performance with PHP go for page controlller :)

Pádraic Brady <[hidden email]> wrote:

>Hi all,
>
>HMVC is basically implemented in PHP all the time. The frameworks claiming this
>are building on two very familiar and old concepts:
>
>1. Composing content via multiple dispatches to controllers within the same PHP
>process.
>2. Relying on their simplicity and lack of features to maintain reasonable
>performance.
>
>ZF1 could do the exact same thing from Day 1 so this means ZF is, oddly enough,
>also a valid HMVC framework. The problem is we, Symfony, Lithium and any other
>large framework have is that this approach simply does not perform
>satisfactorily. Other frameworks claim HMVC purely on the basis that they are
>light enough to reduce the performance penalty to the point where it's
>acceptable. Larger frameworks just cannot compete on this same level - so we end
>up using View Helpers (and similar such lightweight solutions) to do the same
>thing with less code and significantly less processing.
>
>In effect, HMVC is just a new buzzword being used by other frameworks for no
>particular reason.
>
>The interesting aspect of HMVC is splitting the processing across multiple
>threads to increase performance (akin to asynchronous processing). Obviously,
>PHP and Threads don't belong in the same sentence. We can, however, perform
>asynchronous tasks using, as Keith notes, stuff like task and message queueing.
>If we were talking about Ruby, a better example might be EventMachine.
>
>So, HMVC? I don't see it as a ZF2 requirement. Though, keeping an open mind,
>that is based on the limits imposed on us by MVC performance. I'm expecting ZF2
>to hand Symfony's current marketing on the basis of its speed a serious blow ;).
>ZF1 without the bells and whistles is already 12% faster than Symfony 2 based on
>a thoroughly pointless benchmark (which is fun to run anyway :P).
>
>Paddy
>
> Pádraic Brady
>
>http://blog.astrumfutura.com
>http://www.survivethedeepend.com
>Zend Framework Community Review Team
>
>
>
>
>
>________________________________
>From: Keith Pope <[hidden email]>
>To: [hidden email]
>Sent: Tue, May 17, 2011 5:48:48 PM
>Subject: Re: [zf-contributors] HMVC in ZF2
>
>The action view helper is pretty ugly for this kind of thing. It would be better
>if you could route to more than one controller.
>
>I am not tottaly sold on hmvc, if you want to distribute parts of your system
>messaging is probably going to give you more. Rabbitmq, zeromq etc using soa
>posibily cqrs is going to give you a more separation and scalability.
>
>Thx keith
>
>Enrico Zimuel <[hidden email]> wrote:
>
>>
>>>
>>> I agree Benjamin, also, my biggest concern with the HMVC approach (at least
>>> the way I've been reading about it in the more recent frameworks), is this
>>> in-request sub-request. Seems pretty hacky to me. There are far greater
>>> tools available for distributing load. Not to mention, I don't see how this
>>> pattern is used within a console-based application where you are forking
>>> multiple processes off as part of a job queuing system.
>>>
>>
>>This is the defintion of HMVC from the original article appears in the
>>JavaWorld Magazine in 2000 (http://bit.ly/8Scr0h).
>>
>>"The HMVC pattern decomposes the client tier into a hierarchy of
>>parent-child MVC layers. The repetitive application of this pattern
>>allows for a structured client-tier architecture."
>>
>>A lot of PHP frameworks support the HMVC, for instance:
>>
>>Fluency, http://code.google.com/p/fluency/
>>Kohana, http://kohanaframework.org/
>>Alloy, http://alloyframework.org/
>>
>>But I found that they support HMVC differently from the original idea.
>>Basically they support a single request with different controllers in a
>>view, offering the possibility to reuse a subset of the MVC. But this is
>>not the original idea of HMVC where you should have isolated tiers of
>>MVC that communicate each other to manage different pieces of
>>application.
>>
>>This page of the Alloy framework explains the implementation of HMVC:
>>http://alloyframework.org/manual/architecture/hierarchal-mvc/
>>
>>I think if we consider HMVC just the possibility to manage a single
>>request with multiple controllers this is something that we already
>>support in ZF with the Action View Helper.
>>
>>What do you think?
>>
>>
>>--
>>Enrico Zimuel
>>Senior PHP Engineer     | [hidden email]
>>Zend Framework Team     | http://framework.zend.com
>>Zend Technologies Ltd.
>>http://www.zend.com
>>
>>
>>--
>>List: [hidden email]
>>Info: http://framework.zend.com/archives
>>Unsubscribe: [hidden email]
>>
>>

[ThaDafinser]

I just want to vote for this. For me this would be nearly a killer feature
for zf2

Am 16.05.2011 01:51 schrieb "Marten Lienen" <[hidden email]>:

Hello,
first I want to say that I probably dont know the whole current state of
affairs
as far as HMVC is concerned since I just recently subscribed to this list.
Am
I right that ZF2 is going to feature HMVC? Is there a draft implementation?
I
didn't find any. If there is none I will post my draft implementation
tomorrow
for discussion. If there is one I would like to view it and share my
thoughts.

Best regards,
Marten Lienen

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Wil Moore III]

On Tue, May 17, 2011 at 13:52, Martin Keckeis <[hidden email]>
 wrote:

> I just want to vote for this. For me this would be nearly a killer
> feature for zf2
>

Hi Martin,

Can you elaborate on why this is this a killer feature for you?

[basz]

Hi,

reading this HMVC stuff i cant help me think about the binarycloud framework i used to work with and contributed to  with much pleasure. It consisted of a compositing of parent child, all configurable and extendable...

it actually took me a while to figure out that zend doesn't have this layered (or does it different, depending who you ask) and that view helpers are a different way to achieve similar things... when i got used to it i just decided that in most web apps i didn't need these deep tree structures anyway.

The elegance of binarycloud however (i thought) was the way it handled the 'configuration' of its composition. One could -potentially- construct a complete functional component (eg. a form) by writing an xml (node definition file or NDF) and include that in an other NDF.

Nodes would be able to create child nodes configured in the NDF. Nodes could have a default configuration depending on its design/functionality. This configuration/structure data was simple overridable by passing different data to the node when it was constructed. XML ofcourse has parent/child build into, but also had the ability to reference or include (and thus override) other NDF's. It worked nice.

The thing is that binarycloud did perform reasonable, even back in 2004 (I am doubting myself now on if it also worked on PHP 4). It did all kind of tricks of preparsing these xml into php arrays and lots of caching. Unfortunatly it never gained enough traction and I was sad to see it die. The project is now long dead, but if someone is interested i have a copy laying around here from which i pass an example.

hope this helps this discussion.

Bas

example of two Node Definition File (xml)

<node:definition version="2.0" id="top" path="app/top/Top.php"
  xmlns="http://www.binarycloud.com/ns/node"
  xmlns:node="http://www.binarycloud.com/ns/node">
    <template path="app/top/tpl/Top.tpl">
        <param id="title"><![CDATA[binarycloud testsite &raquo; nodes &raquo; complex nodes]]></param>
    </template>
   
    <contains>
        <node:include id="content" definition="app/nodedemo/ndf/ComplexNodeDemo.ndf.xml" />
    </contains>
</node:definition>


<node:definition version="2.0" id="top" path="app/nodedemo/ComplexNodeDemo.php"
  xmlns="http://www.binarycloud.com/ns/node"
  xmlns:node="http://www.binarycloud.com/ns/node">

    <contains>
        <node:definition id="foo">
            <template path="app/nodedemo/tpl/ChildNode.tpl" />
        </node:definition>
        <node:definition id="bar">
            <template path="app/nodedemo/tpl/ChildNode.tpl" />
        </node:definition>
        <node:definition id="another_node">
            <template path="app/nodedemo/tpl/ChildNode.tpl" />
        </node:definition>
    </contains>
</node:definition>


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Marten Lienen]

Hi,
some things have delayed everything by quite a bit. I will just show you
what i've got so far: https://github.com/CQQL/zf2/tree/hmvc
You will find all the library code in /library/Zend/Hmvc and a sort of
small integration test in tests/Zend/Hmvc/TestTest.php. First i want to
say that there are just a few comments and no unit tests since this is a
draft implementation but i will explain everything.
- The interfaces for requests and responses are very small because it
is, as I said, just a draft. There will be richer interfaces
- There are controllers which have a dispatch method to dispatch a
routed request. At the moment there is just one child class:
ActionController. This dispatches requests to ...Action methods just
like ZF1 did but you are supposed to return a Response object yourself.
There could be other extensions of AbstractController like a
MagicActionController which will find and pass a template like ZF1 or a
RestController which dispatches based on the request method.
- The front controller and controller namespaces are separated but i
think front controllers should implement the Controller interface. Hm, i
think there is no further explanation needed as the code is pretty
selfexplanatory.
- The router parses the request to ControllerCall objects. There could
be some other implementations like a regex based router, a static router
and a RouterChain which fulfills the chain of responsibility pattern.
- The dispatcher creates an instance of the requested controller and
calls it's dispatch method. The current implementation works with
namespaces but again there could be a BC implementation with oldschool
dispatching
- The Response interface has received least thoughts until today since I
just had not enough time. My idea for this is that a response object
takes another object which fulfills an ResponseParser (name is very bad
though, i just cannot think of a better one) so that you can write
adapters for Zend\View, smarty, Twig, parsing on call, delayed parsing
and so on.

A very important point is that in order to make use of the Controller
constructor the controllers will have to be instanced by a DI-container.

I am looking forward to your thoughts and criticism.

Best regards,
Marten Lienen

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[ThaDafinser]

Hello Wil Moore,

first sorry for the late response.

Let me explain a little bit further, why HMVC would be a killer feature for
me:
I'm developing an application (not website) and an application is about 90%
following:
* Listing datasets
* Modifing data (create / edit / delete)

So in 90% of my cases i also don't use a classic "view".
Because the form and the listing is in classes (Zend_Form and my own
datagrid).
Which is very important for maintanance.

But when i want to display a form and next to it some subinformations in one
or more lists i can't do this right.

For example:
* display the data of a single person in a form
* list the users of this person (this list could also be displayed at
different pages of the application)
* list the teams of this person
* ....

Currently i use the "ugly" approach with "_forward()".
Where are two problems with this method:
* it dispatching all again
* i can only forward from one controller to another and not from one to
"many"

Best regards
Martin keckeis

2011/5/17 Wil Moore III <[hidden email]>

> On Tue, May 17, 2011 at 13:52, Martin Keckeis <[hidden email]>
>  wrote:
>
> > I just want to vote for this. For me this would be nearly a killer
> > feature for zf2
> >
>
> Hi Martin,
>
> Can you elaborate on why this is this a killer feature for you?
>

[David Muir]

ThaDafinser,

I don't see how HMVC would solve your problem any better than using view helpers.

David

[Marten Lienen]

Hi,
isn't there any feedback or am I just not experienced enough to handle a
mailing list correctly? Perhaps I hit the wrong button to reply.

Best regards,
Marten Lienen

PS: The original message is in the quote below.

Am 5/17/2011 10:27 PM, schrieb Marten Lienen:

> Hi,
> some things have delayed everything by quite a bit. I will just show
> you what i've got so far: https://github.com/CQQL/zf2/tree/hmvc
> You will find all the library code in /library/Zend/Hmvc and a sort of
> small integration test in tests/Zend/Hmvc/TestTest.php. First i want
> to say that there are just a few comments and no unit tests since this
> is a draft implementation but i will explain everything.
> - The interfaces for requests and responses are very small because it
> is, as I said, just a draft. There will be richer interfaces
> - There are controllers which have a dispatch method to dispatch a
> routed request. At the moment there is just one child class:
> ActionController. This dispatches requests to ...Action methods just
> like ZF1 did but you are supposed to return a Response object
> yourself. There could be other extensions of AbstractController like a
> MagicActionController which will find and pass a template like ZF1 or
> a RestController which dispatches based on the request method.
> - The front controller and controller namespaces are separated but i
> think front controllers should implement the Controller interface. Hm,
> i think there is no further explanation needed as the code is pretty
> selfexplanatory.
> - The router parses the request to ControllerCall objects. There could
> be some other implementations like a regex based router, a static
> router and a RouterChain which fulfills the chain of responsibility
> pattern.
> - The dispatcher creates an instance of the requested controller and
> calls it's dispatch method. The current implementation works with
> namespaces but again there could be a BC implementation with oldschool
> dispatching
> - The Response interface has received least thoughts until today since
> I just had not enough time. My idea for this is that a response object
> takes another object which fulfills an ResponseParser (name is very
> bad though, i just cannot think of a better one) so that you can write
> adapters for Zend\View, smarty, Twig, parsing on call, delayed parsing
> and so on.
>
> A very important point is that in order to make use of the Controller
> constructor the controllers will have to be instanced by a DI-container.
>
> I am looking forward to your thoughts and criticism.
>
> Best regards,
> Marten Lienen
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Wil Moore III]

I replied a couple days ago; however, I see it is not showing up in Nabble. I really hope we can move this entire list to Google Groups at some point. This is getting a bit crazy. Anyhow, what I wrote is below:

ThaDafinser wrote

 first sorry for the late response.

Nice of you to say so, but I wasn't expecting an instant response -- we've all got things to do right :)
 

ThaDafinser wrote

I'm developing an application (not website) and an application is about 90% following:
* Listing datasets
* Modifing data (create / edit / delete)

Depends on the application -- but point taken. This is your current use-case.
 

ThaDafinser wrote

So in 90% of my cases i also don't use a classic "view".
Because the form and the listing is in classes (Zend_Form and my own datagrid).
Which is very important for maintanance.

Glad to hear it as I can speak to that because 90% of my web applications generally follow the same pattern.

ThaDafinser wrote

For example:
* display the data of a single person in a form

We handle this with a service object that wraps a hydrated entity (plain PHP object). The service exposes crud functionality and provides some convenience methods so the interface is as dry as possible. This is also fully tested via unit tests and functional tests.

These services also return the data as a zend paginator iterator.

ThaDafinser wrote

* list the users of this person (this list could also be displayed at different pages of the application)

We handle this via repositories -- An eager load or a fetch join to this one-to-many association provides the down-level data. I assume you display this as a sub-grid or as a hide-show panel near the form. The data could be fetched all at once and provided to the view via a partial or you could make an asynchronous JSON request to load on demand.
 

ThaDafinser wrote

* list the teams of this person

Same pattern as above. Of course, there are other ways to do this which are just as simple and just as effective.
 

ThaDafinser wrote

Currently i use the "ugly" approach with "_forward()".
Where are two problems with this method:
* it dispatching all again
* i can only forward from one controller to another and not from one to "many"

You really can avoid doing it that way -- if HMVC is what you believe will do it for you, that's fine, but there are other really nice ways to do these things :)

[weierophinney]

-- Marten Lienen <[hidden email]> wrote
(on Thursday, 19 May 2011, 05:36 PM +0200):
> isn't there any feedback or am I just not experienced enough to
> handle a mailing list correctly? Perhaps I hit the wrong button to
> reply.

As noted in a previous email on another thread, my team and I are having
some issues with getting mails from our own mailing lists. I was
planning on hitting Nabble today or tomorrow to go through and see what
we may have missed -- this was obviously one of them.

One note: what you describe sounds possible with the proposed ZF2
interfaces already in many ways; it's simply a matter of getting
controllers, crafting a request, and dispatching said controller.

> PS: The original message is in the quote below.
>
> Am 5/17/2011 10:27 PM, schrieb Marten Lienen:
> > Hi,
> > some things have delayed everything by quite a bit. I will just
> > show you what i've got so far:
> > https://github.com/CQQL/zf2/tree/hmvc
> > You will find all the library code in /library/Zend/Hmvc and a
> > sort of small integration test in tests/Zend/Hmvc/TestTest.php.
> > First i want to say that there are just a few comments and no unit
> > tests since this is a draft implementation but i will explain
> > everything.
> > - The interfaces for requests and responses are very small because
> > it is, as I said, just a draft. There will be richer interfaces
> > - There are controllers which have a dispatch method to dispatch a
> > routed request. At the moment there is just one child class:
> > ActionController. This dispatches requests to ...Action methods
> > just like ZF1 did but you are supposed to return a Response object
> > yourself. There could be other extensions of AbstractController
> > like a MagicActionController which will find and pass a template
> > like ZF1 or a RestController which dispatches based on the request
> > method.
> > - The front controller and controller namespaces are separated but
> > i think front controllers should implement the Controller
> > interface. Hm, i think there is no further explanation needed as
> > the code is pretty selfexplanatory.
> > - The router parses the request to ControllerCall objects. There
> > could be some other implementations like a regex based router, a
> > static router and a RouterChain which fulfills the chain of
> > responsibility pattern.
> > - The dispatcher creates an instance of the requested controller
> > and calls it's dispatch method. The current implementation works
> > with namespaces but again there could be a BC implementation with
> > oldschool dispatching
> > - The Response interface has received least thoughts until today
> > since I just had not enough time. My idea for this is that a
> > response object takes another object which fulfills an
> > ResponseParser (name is very bad though, i just cannot think of a
> > better one) so that you can write adapters for Zend\View, smarty,
> > Twig, parsing on call, delayed parsing and so on.
> >
> > A very important point is that in order to make use of the
> > Controller constructor the controllers will have to be instanced
> > by a DI-container.
> >
> > I am looking forward to your thoughts and criticism.
> >
> > Best regards,
> > Marten Lienen
> >
>
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Marten Lienen]

Ok, i have just looked at the Zend\Controller\ActionController
interface. Why does the dispatch method take the action as an argument?
This might seem handy if you think about "normal" controllers, but you
can see the problem when take a look at Zend\Rest\Controller. Other
classes need to know which specific controller an object is an instance
of to handle it correctly or further gone they have to know about the
inside of the class. This does not seem right. All this would be
prevented if the dispatch method took the request object as an argument
and encapsulates the method dispatching process internally.

As you have probably noticed I am quite new to zend framework
contribution or opensource at all. Where am I supposed to put my
thoughts at? I read that discussions should be made on the proposal
pages but that really lack an easyly overlookable structure. Is there no
forum or something? And is there a place where I can look up the
decision making process?

Am 5/19/2011 9:26 PM, schrieb Matthew Weier O'Phinney:

> -- Marten Lienen<[hidden email]>  wrote
> (on Thursday, 19 May 2011, 05:36 PM +0200):
>> isn't there any feedback or am I just not experienced enough to
>> handle a mailing list correctly? Perhaps I hit the wrong button to
>> reply.
> As noted in a previous email on another thread, my team and I are having
> some issues with getting mails from our own mailing lists. I was
> planning on hitting Nabble today or tomorrow to go through and see what
> we may have missed -- this was obviously one of them.
>
> One note: what you describe sounds possible with the proposed ZF2
> interfaces already in many ways; it's simply a matter of getting
> controllers, crafting a request, and dispatching said controller.
>
>> PS: The original message is in the quote below.
>>
>> Am 5/17/2011 10:27 PM, schrieb Marten Lienen:
>>> Hi,
>>> some things have delayed everything by quite a bit. I will just
>>> show you what i've got so far:
>>> https://github.com/CQQL/zf2/tree/hmvc
>>> You will find all the library code in /library/Zend/Hmvc and a
>>> sort of small integration test in tests/Zend/Hmvc/TestTest.php.
>>> First i want to say that there are just a few comments and no unit
>>> tests since this is a draft implementation but i will explain
>>> everything.
>>> - The interfaces for requests and responses are very small because
>>> it is, as I said, just a draft. There will be richer interfaces
>>> - There are controllers which have a dispatch method to dispatch a
>>> routed request. At the moment there is just one child class:
>>> ActionController. This dispatches requests to ...Action methods
>>> just like ZF1 did but you are supposed to return a Response object
>>> yourself. There could be other extensions of AbstractController
>>> like a MagicActionController which will find and pass a template
>>> like ZF1 or a RestController which dispatches based on the request
>>> method.
>>> - The front controller and controller namespaces are separated but
>>> i think front controllers should implement the Controller
>>> interface. Hm, i think there is no further explanation needed as
>>> the code is pretty selfexplanatory.
>>> - The router parses the request to ControllerCall objects. There
>>> could be some other implementations like a regex based router, a
>>> static router and a RouterChain which fulfills the chain of
>>> responsibility pattern.
>>> - The dispatcher creates an instance of the requested controller
>>> and calls it's dispatch method. The current implementation works
>>> with namespaces but again there could be a BC implementation with
>>> oldschool dispatching
>>> - The Response interface has received least thoughts until today
>>> since I just had not enough time. My idea for this is that a
>>> response object takes another object which fulfills an
>>> ResponseParser (name is very bad though, i just cannot think of a
>>> better one) so that you can write adapters for Zend\View, smarty,
>>> Twig, parsing on call, delayed parsing and so on.
>>>
>>> A very important point is that in order to make use of the
>>> Controller constructor the controllers will have to be instanced
>>> by a DI-container.
>>>
>>> I am looking forward to your thoughts and criticism.
>>>
>>> Best regards,
>>> Marten Lienen
>>>
>>
>> --
>> List: [hidden email]
>> Info: http://framework.zend.com/archives
>> Unsubscribe: [hidden email]
>>
>>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]