The V part in an MVC model when applied to a CMS

Question

With a CMS (PHP/MySQL) that's getting bigger and bigger and its code harder to maintain, I'm thinking of applying an MVC model to make it more maintainable and transparent. I've been doing some catch-up on the subject, and I think I have it pretty much figured out, except for the views part. Here's what I have in mind so far:

index => controllers <=> models
         controllers  => views

An index.php that acts as the main controller (router) and creates instances of controller classes based on params in the URL. The controller classes talk to a model classes for updating and retrieving information in/from the database. And after that the controller makes sure the view (in the form of templates) is displayed and receives processed data to display. However...

The idea is to shift all the logic from the view to the controller, right? Or at least away from the view — to prevent a fat/skinny controllers/models discussion. But whichever way I look at it, I still need somewhat dynamic views and that will also require some logic. For instance displaying certain options for certain users based on their user level and rights (update, update/delete, etc.). So that will come down to if/else statements and things like that. Is this OK? And if so, how much of this 'simple' logic is 'allowed'? My take is up to a point where a different template starts to make more sense (e.g. profile_view and profile_edit).

Another simple example. Say one user can see 5 out of 10 profile fields, and another user 10/10. Should I retrieve all the information for all 10 fields through the controller, and determine in the view whether or not to display it? Or move those kinds of decisions to the controller as well, and retrieve information for either 5 or 10 fields and display only the available fields in the view based on the information that has been passed on? Because in many situations it's much easier have all the data and disregard some of it, opposed to not knowing what is available and having to check for that all the time.

Answer 1

To the second example: Don't pass all the 10 fields just the visible ones, filter the invisible elements in the controller, and keep the view simple as it possible.

Answer 2

In my understanding and application of MVC, the controller contains business / application logic but the view can contains presentational logic. You want your views to be as simple and specific as possible, but you don't want to be generating HTML (for example) in your controller and just displaying that in the view.

Answer 3

"So that will come down to if/else statements and things like that. Is this OK?"

Yes.

"how much of this 'simple' logic is 'allowed'?"

Simple if-else and simple loops must be present in the view templates.

No calculations. No form-handling logic. None of that.

If you look at some of the more sophisticated frameworks, you can see some examples. Indeed, you should probably just use a framework instead of rolling your own.

[If you have the patience to read the Python-based Django template documentation, you can see what should be allowed. There are probably some PHP frameworks with a similar philosophy.]

"Say one user can see 5 out of 10 profile fields, and another user 10/10"

There are several approaches.

1. Two different page templates showing the same underlying data. You fetch everything, but pick a template appropriate to the user.

2. One complex template showing variant underlying data. You fetch everything, provide suitable flags, and send to a template which uses template-side if-statements.

Which is "better"? Depends on your appetite for complex pages. Personally, I'd prefer to have two simple pages and use some kind of inheritance to factor out the common features. I don't like if-statements, they're a cause of problems down the road. OTOH, some folks like if-statements and don't mind the complexity.