2

I've been having this discussion for a while already and I would like to know the broad opinion and reasons for the people in here.

The context

This question is about the theoretically correct scopes of a View in a MVC Model in PHP.

The so-far-understood

In a MVC design, the View part should be responsible of painting a page or part of it. This means that the View will paint static content and parameters build with PHP. In some cases some flow control logic is required here - foreachs, fors.

The problem

I thought that View side of the MVC should be extremely dumb - being the filters and formats of the parameters handled by the Libraries that generate these parameters...

However, some template engines like Twig or Smarty supports the idea of having format controllers in the View, being acceptable to filter and format currencies, dates, etc.

Where are then the limits of the "intelligence" of a View? If the filters and formats are acceptable of a View, what about conditional formats? For example, if the Date format can be set by the User, then the View must know about this setting - and if we allow this we can extend the View knowledge for currencies, languages, etc...?

Thanks!

Hector Ordonez
  • 1,044
  • 1
  • 12
  • 20
  • I like this question but so far I'd say it's "Primarily opinion based". For example, I personally like dumb views too, even if i use Smarty: I rarely use variable modifiers, but i often use IFs and FOREACHs. On the other hand, somebody might prefer to leave the controller as thin as possible, and leave to the view the rendering details, making them "smart" views. – STT LCU Oct 16 '13 at 12:26
  • I agree with thin controllers, being their only role to "control" what user requests and who is gonna build the answer. But that does not mean imo that view has to handle logic beyond the Ifs and Foreachs - it might be so, but an explanation why would be cool. – Hector Ordonez Oct 17 '13 at 08:27

1 Answers1

1

Think of MVC as a set of guidelines rather than strict rules. You can go ahead and make the worst app ever by having presentation parts in the model and the controller, db communication in the view, etc. Nothing can stop you, right? (for the comment: Of course, I'm in no way suggesting you should do this!, just saying that the app might still work even though it's written in the worst way possible)

So I guess the inteligence limit of a view is what best works for your app - for one app, having certain filters is perfectly fine (in case the app really makes use of them), while for another one it might be considered bad practice. As long as you know what happens in each MVC components, you're free to fine-tune the boundaries of each of them, as needed by the application you're building. There just isn't a single correct usage.

Shomz
  • 37,421
  • 4
  • 57
  • 85
  • *"A view requests information from the model that it needs for generating an output representation to the user"* .. as per https://en.wikipedia.org/wiki/Model_view_controller . MVC is not "a set of guidelines". A guideline is "put a whitespace between `if` and `(`". MVC **is** a set of constraints that is imposed on application's high-level structure. – tereško Oct 16 '13 at 12:35
  • I know what a view is, my point was that the boundaries aren't clean. I've added a disclaimer for you. And I never said MVC *was* a set of guidelines, but OP should consider it as such as opposed to the set of strict rules. – Shomz Oct 16 '13 at 12:37