Why split the View in MVC into a view class and a template

Question

I'm relatively new to design patterns but I feel that I've got a good understanding of the MVC pattern and the advantages that this separation of code brings.

However, both times I've seen the MVC pattern in action (Magento and Joomla!), there is further specialization, with the view consisting of both a view class (Magento block) and a PHP template file. I would appreciate it if someone could explain the benefit of this split.

I'm also at a loss as to how to split my code between the view class and the template file. Sometimes I find myself writing what seems to be a redundant view class (in Joomla!) which simply accesses the model and then just makes the data available for the template. What code should appear in the template and what code should appear in the view class?

Answer 1

View, in MVC-inspired design patterns, are responsible for all of you UI logic. They should be requesting information from model layer and, based on what they receive, choosing which templates should be used for creation of the response. Or even if any rendering is required (view can just as well just send a HTTP header).

_{You could say that in classical MVC and Model2 MVC patterns, the view only reads from model layer, but controller only writes to it.}

If you receive some error state from model layer, the view takes the main layout template and supplements it template, which is contains HTML fragment for error messages. Then it assembles the whole thing an shows to the user (which, in case of web applications is the browser).

Templates, in your basic web application, are just simple files with a mix of tags and php variables.

Answer 2

You can consider the view as the what and the template as the how.

The view prepares the data by using the model and makes this data available to the template.

The template, in turn, is usually called (in Joomla!, at least) in the view's scope.

This may seem kind of redundant at first, but the power of this approach is revealed when using template overrides. Then, the view can be left alone, and only the template (or sub-templates, for this matter), be overridden.

Even using the same main (Joomla!) template, you may specify a different view template as a parameter, in case you need some specialization of presentation. This also eliminates code repetition.

For example, say you create a new main template. You can override some of the default views/templates and leave some others untouched. Then, you can create a new view, say, blog view, and also 2 templates for it, light spaced and dark dense, to be used in 2 different scenarios. This way, you only have one view to prepare all of the what and several different templates to take care of the how.