views:

139

answers:

5

Hi, I get data from Model (an array with data) and I need to display with a specific format. I need to iterate over the array, format the data and then display it. Where should I format data to display? In Model, Controller or View? Thank you.

+5  A: 

Iteration over an array and displaying the data is done in the view. Therefore I would also do the formatting in the view. If formatting is complicated and/or requires a lot of code, put it in a helper function.

For example:

View:

<?php foreach($array as $item): ?>
    <p><?php echo format_function($item); ?></p>
<?php endforeach; ?>

Helper:

function format_function($text)
{
    // Do some formatting here...
    return $formatted_text;
}
captaintokyo
Helper function sounds good :)
jared
Do NOT pollute your view with such a crap. The view is not responsible for formatting. Try to use a seperate layer who is responsible for formatting/transforming your object model into a view friendly view model :) Like Stefanvds said in .NET there exists an object-to-object mapper called AutoMapper maybe there is an equivalen in php.
Rookian
I don't agree. Every MVC framework I know has out-of-the-box support for this. If not for cases like this, then what should I use helpers for? Your solution maybe more 'pure', but in this simple case I feel adding another layer is overdoing it.
captaintokyo
The pro of having an extray layer is that you could say, if the object type is datetime you always use the special date formatter instead of having views where you repeat the calls to your datetimeformat helper method. So you do not vioalte the DRY Principle.
Rookian
@Rookian, I disagree with your statement that the view is not responsible for formatting. I qualified the statement that the view should not handle any application logic.
Syd
+2  A: 

if your viewdata has data from different models, or has only a select part of 1 model, you could make a ViewModel, which you then could map with Automapper.

ViewModels have several advantages. They are clear to work with, unclutter your data, can add safety,...

Stefanvds
any links with details to that pattern?
Gordon
@Gordon: http://en.wikipedia.org/wiki/View_model ?
fabrik
@fabrik For other uses, see [View model (disambiguation)](http://en.wikipedia.org/wiki/View_model_%28disambiguation%29). Never hurts to have a link when referencing a pattern.
Gordon
I didn't heard about it before. I'm going to read that right now! Thank you.
jared
+2  A: 

You can do it in View.Not in model In View you can do specific operation(converting/conditions/)

Oyeme
A: 

If you working on a bigger project, I would suggest you to have an extra layer or class that is responsible for transforming your object (i.e. domain model object) into a data transfer object (view model object).

Otherwise apply the suggestions of doing the formatting in the view :)

The transforming could be involved with formatting strings, decimals (currency), datetimes and so on. Also transform an object graph (have a look at my example) into a flat DTO is possible.

The controller would be responsible for calling the mapping algorithm.

So in the view you do not have to iterate over references of your object. Instead you use a flat well formatted view model.

Your view will not cluttering up and looks very clean.

A tool that does this transforming job is available in the .NET world. It is called AutoMapper. Perhaps there is an equivalent in PHP.

Here is an example

This is an object model: alt text

You could transform it into this smart view model:

alt text

The advantages of this approach:

  • seperation of concerns

  • clean view

  • No code duplications, i.e. formatting a datetime in each view. (Don't repeat yourself!)

The disadvantages of this approach:

  • expensive for the beginning, so little projects do not profit from this approach
Rookian
A: 

Do it in your View as it is responsible for the presentation.

The reason for

  • not doing it the Model is that you can then render different views using the same data (otherwise you need to create different set of data),
  • not doing in the controller is because it is not the Controller's responsibility

See MVC background reading

Syd