I've worked fairly extensively with the MVC framework cakephp, however I'm finding that I would rather have my pages driven by the multiple MVC than by just one MVC. My reason is primarily to maintain an a more DRY principle.

In CakePHP MVC: you call a URL which calls a single MVC, which then calls the layout. What I want is: you call a URL, it processes a layout, which then calls multiple MVC's per component/block of html on the page.

When you compare JavaScript components, AJAX, and server side HTML rendering, it seems the most consistent method for building pages is through blocks of components or HTML views. That way, the view block could be situated either on the server or the client.

This is technically my ONLY disagreement with the MVC model. Outside of this, IMHO MVC rocks!

My question is: What other RAD frameworks follow the same principles as MVC but are driven rather by the View side of MVC?

I've looked at Django and Ruby on Rails, yet they seems to be more Controller driven.

Lift/Scala appears to be somewhat of a good fit, but i'm interested to see what others exist.

I'm not sure of the details of CakePHP, but when you say "a URL which calls a single MVC", do you mean that a URL is routed to a single action?
–
StuperUserJun 17 '11 at 8:42

@StuperUser, yes, that is correct. The URL is routed to a Controller.Action, which then sends its results to the layout for rendering the rest of the page contents. At that point, its no longer MVC, but html templates pulled together.
–
lordgJun 17 '11 at 14:32

5 Answers
5

I think what you're thinking of is a concept called HMVC, which stands for Hierarchical Model View Controller.

What this means is that when you're rendering your view, you are able to dispatch a request to a completely different controller and return that view and echo it out. It behaves exactly like an ajax request, except it does not go through http, it goes through the framework and doesn't make an additional request.

This is not common in most frameworks, and the people who don't know about HMVC don't know what they're missing. It cleans up a lot of ugly patterns you see in regular MVC applications.

For example, you have a shopping cart on each page. Wouldn't it be nice to make a call to the shopping cart controller from within your code, and then allow it to handle the rendering and stuff? You can show different views for different states. Trying to do that in a class or a helper method is just a mess.

Anyways, what you came here for is a framework that works like this. The answer is Kohana. Here's the relevant docs.

Here's an example of it in use:Request::factory('shopping_cart/display_items')->execute()-body;

You probably won't find a flavour of MVC that involves a View doing anything.

As you know, in MVC the Views are supposed to be as "stupid" as possible to get good Separation of Concerns.

The request is routed to an action on a controller which does all of the logic on the model, and decides what to display and sends this to a view.

Since you can reuse Client code and views, I don't understand what aspect of MVC you're finding incompatible with the DRY principle?

If you want each page to take care of its own logic, ASP.NET has view-behinds and the Page model, but since it is essentially a web translation of WinForms, its state driven nature isn't really right for the Web (since HTTP is stateless), hence the current popularity and migration of developers to ASP.NET MVC.

You are correct, the Views are stupid. In CakePHP you can have Elements, which are somewhat smarter Views. Inside the Element, you can fetch data from a Controller/Action and then produce the html with the rest of the Element. This is more DRY than the Controller > View method. It also has the advantage of being similar to View-Bindings that I've experienced (very limited at that) with what you say about ASP.NET.
–
lordgJun 16 '11 at 17:32

If the code in the example element is in a helper/service in the domain, that is called by a number of actions, it's just as re-usable. In fact, it should be, to prevent the anaemic domain anti-pattern. The controller actions should do as little business logic as possible and be concerned with choosing views based on the decisions made in the domain.
–
StuperUserJun 16 '11 at 17:42

As StuperUser said, MVC is based around the View being "stupid" or "thin," and honestly, it sounds like you might have a misunderstanding of MVC fundamentals somewhere (not necessarily, hard to do, in my experience, since MVC can be hard to understand if not explained well), if you're finding yourself copying code in controllers.

That said, you might want to take a look at the M-V-VM (Model, View, View-Model) structure that .Net's WPF and Silverlight technologies use (or at least used as of 3.5). It's based on MVC, but has some of its own rules and might be closer to what you're looking for.

Yes, you are correct, I've used it many times. Although it partially solves the problem, it suffers on performance without caching. An ideal system for me would be one that is built to do the requestAction style page building. This is what I'm looking for.
–
lordgJun 17 '11 at 14:35

ASP.NET MVC has a 'RenderAction' that you can call from within inline code in your view. I don't like it personally; I prefer to build compound models around a layout and let 'main view' models derive from it.

I may use a little builder or factory to instantiate the (compound) model to help me instantiate the composition. This is mostly to keep my controllers clean of knowledge about other sub-views.

Using this strategy I can have each partial view peel off it's own sub-model from the compound model or have the layout do it for a partial view.

I found that most MVC system have the render action concept. They just are not built as a central mechanism to the systems. The systems appear to primarily be built around a primary Controller.Action for a url request, which is then fed off to the Layout render for the rest of the page build.
–
lordgJun 17 '11 at 14:39