5

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.

lordg
  • 247

5 Answers5

3

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;

ryeguy
  • 267
2

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.

StuperUser
  • 6,163
1

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.

Shauna
  • 3,529
  • 2
  • 22
  • 19
1

In CakePHP you can do what you ask for with requestAction. It is generally not advised because of performance issues, but works well, especially with cached content.

Andrea
  • 5,425
1

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.

Robert Harvey
  • 200,592
Joppe
  • 4,616