Sorry this was confusing, I took it from the book "A System of Patterns", and they describe not a web application. So the model could change during Runtime and the view needs to be updated immediately. So they use an observer pattern behind the MVC pattern in order to react on events.
- View components display information to the user. A view obtains the
data from the model. There can be multiple views of the model.
- Each view has an associated controller component. (!?)
Each view creates a suitable controller. There is a one-to-one relationship between views and controllers. Views often offer functionality that allows controllers to manipulate the display.
I am very impressed by the http://www.rubyonrails.org/ Framework, I watches those videos and I am in love :-)
Especially the Components solution is impressive. In my eyes this is a better solution for a complex page then the ActionChaining Concept. It abstracts the ideas from the HMVC solution. The different is that not the Controller chooses “SubMVCs”, instead the View includes “SubMVCs”:
The advantage I see is, that the main controller stays so simple as possible and to me it is more part of the View to include SubMVCs (like a Header, Footer, some Boxes (Login, Search ...)). Like I said before:
<%= render_component(:controller => 'image', :action => 'recent_image') %>
The SubMVC-Modells are so View related ... For example if the user chooses not the "Product-Website-View" but instead the "Product-Minimal-Cellphone-Website-View" (Product is shown, but without some boxes ...)
Components to heavy in some cases?
As you can see, it is possible that, with components, Rails developers will be even more capable of sharing code. Additionally, if you intend for the users of your software to alter the views of the application (which is common), it allows you to provide those users with even greater flexibility in regard to what can be displayed without additional work and configuration files on your part, and without them having to modify the controller code.
Rails’ components offer one final feature. For those of you interested in being as modular as possible, there is the components directory (found one level below app). This directory is meant to hold other directories which contain entire subsets of functionality: controllers, models, and views. The allows the components to exist entirely outside of the standard app directory and makes for simple tar/untar style distribution and installation.
From this point forward, your models, views, and controllers should be coded just as they would be normally ...
Think abou a very simple box on the page with an image and some text inside.
Sure, it don't make sense to implement a SubMVC for that?! In that case you are free to use for example the ViewHelper Pattern.
And ... You are not restricted to call the SubMVC Components from the View, of cause you still have the possibility to involve them from the Controller:
Secondly, there is render_component within the controller. This has the effect of passing both control flow and view rendering off to the component being called. This is useful if you have a controller that implements logic to determine what should be displayed but would prefer to utilize code already in a component method to handle the rest of the logic once it’s determined what is needed to be done. It allows for your code to be more DRY (don’t repeat yourself).
The next thoughts ...
Page Controller or Frontcontroller?
There is an nice article from Harry:
The Front Controller and PHP
He is not a friend of a Frontcontroller, and I think so too.
That said, looking at some of the frameworks inspired directly by Jakarta struts, such as php.MVC, phrame, ambivalence and eocene, all use a central configuration file which contains information about the entire website. There's a tale to tell here about what happens when you try to apply Java to rigorously to PHP... One other that takes an interesting "middle ground" is ISMO, distributing most of the command hierarchy to the file system in a similar manner to eZ publish but using class methods instead of a switch statment for handling the final actions.
All of these pass requests through a single script, which often hurts when it comes integrating or making significant modifications to your site later.
It might also be argued that this approach to implementing a Front Controller in PHP does alot to raise the learning curve required to become fluent with the framework, which is significant if you're not convinced about the "vendor".
The solution from WACT:
But what about...?
To say that passing all requests through, say, index.php "is evil" is wrong.
The big advantage of doing this is it makes it very easy to deal with "global operations", which have to happen on every page of your site, such as logging, authentication / session checking and dealing with such things as HTTP client cache headers.
So ... this is my favourite solution for MVC and SubMVCs:
The Base Controller
When multiple page controllers share duplicate logic, a common practice is to move that logic to a base page controller which each page controller can inherit from. This is one way of implementing CentralizedRequestLogic.
ASP.NET provides a special mechanism for implementing base controllers in scripts, called CodeBehind.
When the base controller class begins to have special case logic in it for types of requests, it might be a good idea to consider a FrontController instead.
And now ... ? :-)
A real world example in PHP would be nice ;-)