10

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.

jared
  • 101
  • 1
  • 3

6 Answers6

5

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;
}
Mischa
  • 42,876
  • 8
  • 99
  • 111
  • 4
    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 Sep 14 '10 at 15:09
  • 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. – Mischa Sep 14 '10 at 15:59
  • 1
    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 Sep 14 '10 at 18:35
  • @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 Sep 14 '10 at 23:28
  • I put this methods as a static method inside a class, E.g. `formatUtils::format($string)` – OrangeTux Aug 22 '12 at 07:01
  • @Rookian I agree that there should be another layer. How would you suggest setting the format? If I wanted something in json would I get that format from the query in the controller and pass that along to the format layer? – Katrina Apr 27 '15 at 14:19
2

Presentation != data formatting. Please consider the following example:

A international shop with has a product page, with various information regarding product dimensions, etcetera. Because of the international nature of the shop, this data should be formatted differently for each locale the shop is visited in. For example: In Europe, measurements are shown as metric values, whereas US clients see the same data formatted as imperial values.

An important note is that this particular type of data shouldn't be stored multiple times for each format, though data regarding prices for example should. This is because of the fact that product prices do differ per locale. Measurements and dates on the other hand are universally equal across different locales; only the way they are displayed and formatted differ. Information should always be stored with as little redundancy as possible.

The view portion of such an shop (or any MVC-based application, for that matter) shouldn't do anything else besides rendering the data and determining how this data is presented to the user. The data itself shouldn't be changed by the view in any way. This is exactly why information regarding measurements and time should be stored in a ISO standardized format, which makes formatting the data to other formats more easy. Measurements should be stored as metric values for example. The actual formatting of data per locale should take place in the model after the dataset is retrieved from the database, preferably with a statically accessible Helper-type class for the most flexibility. After the data is formatted, it's returned to the controller which then returns it to the current view.

Another important upside of this way of handling data formatting, is that your data still will be correctly formatted when you try and get the dataset via a view-less action (ie. a JSON object retrieved via AJAX). Data that is sent back to the client in any way (via a "normal" HTML template or as an JSON/XML string) shouldn't differ; only the way it is presented.

Max van der Stam
  • 286
  • 1
  • 9
  • Agreed. SoC is about responsibility, and typically in a presentation architecture w/ a passive view (like the MVP variation, MVVM, MVPVM etc.), formatting/data prep responsibility is not the responsibility of the view. It would be the presenter/viewmodel, and in the case of the more "MVP-style" ASP.Net MVC for example, the controller better yet, a vm). Passivity increases testing/reuse, keeps biz logic out of presentation. And the last para made a great point I hadn't thought of, which also means "formatted" doesn't have to means formatted for viewing. – galaxis Sep 05 '17 at 05:26
2

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
  • 5,868
  • 5
  • 48
  • 72
  • any links with details to that pattern? – Gordon Sep 14 '10 at 12:21
  • @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 Sep 14 '10 at 12:27
  • I didn't heard about it before. I'm going to read that right now! Thank you. – jared Sep 14 '10 at 12:39
2

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

Oyeme
  • 11,088
  • 4
  • 42
  • 65
2

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
  • 19,841
  • 28
  • 110
  • 180
2

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
  • 1,526
  • 1
  • 15
  • 16