Where should number_format (logic relating to the view) go un CakePHP?

Question

After discussing with a colleague, we are mixed in where we think logic relating to the view should go.

For example lets say we have a number that we want to show in our view. I think the number_format (or CakeNumber::format as we're using CakePHP) should go in the view as it's related to what we show. My colleague thinks it should go in the controller because that's where all logic goes.

In this case we have two views, one for the website and end users and an API view which returns a json response. If I were to put the code in the controller I'd have to check which view I'm using as not to give a string in the json response when really it is an integer. For this reason I'm heavily supporting the code in the view.

The question is, who is "more" right, where should that number formatting go?

Further to my argument of putting code in the view, he is happy to use htmlentities in the view but I argue that if I'm not allowed number_format, he can't have htmlentities and that it should be done in the controller.

Answer 1

For example lets say we have a number that we want to show in our view. I think the number_format (or CakeNumber::format as we're using CakePHP) should go in the view as it's related to what we show. My colleague thinks it should go in the controller because that's where all logic goes.

Your buddy is wrong. You should use the NumberHelper in fact which is a wrapper around the static CakeNumber. You usually want to avoid statics and singletons in your app, also a helper can be aliased, so use the NumberHelper in the views. The view is the right place.

In this case we have two views, one for the website and end users and an API view which returns a json response. If I were to put the code in the controller I'd have to check which view I'm using as not to give a string in the json response when really it is an integer. For this reason I'm heavily supporting the code in the view.

The controller doesn't need to have a single line changed to support json and other output. Well, you can use the built in serialization of the view vars to json/xml OR build custom json views. Read this chapter. However, there is no need to create two methods or fill the controller with business logic which is in fact wrong.

The question is, who is "more" right, where should that number formatting go?

Definitely the view.

A controller should be skinny and not contain any business logic:

Further to my argument of putting code in the view, he is happy to use htmlentities in the view but I argue that if I'm not allowed number_format, he can't have htmlentities and that it should be done in the controller.

Use h() which is a shortcut for htmlspecialchars(). And make sure you use it for everything you echo there. All the core helpers that come with the framework will do that internally for you if you pass something through them but pay attention to third party helpers that might not use it!

Answer 2

According to the rules of MVC all logic should go in the model, not the controller The controller should only pull everything the view needs together, then hand it off to the view to be displayed.

That having been said in my experience the View often ends up with small parts of logic in it. Converting the formatting a number or escaping content with htmlentities is all very minor stuff in the end and is fine to be in the view, some people would even consider using those functions as formatting rather than business logic. Lots of people, myself included, refer to small functions such as these as helpers (as pointed out by Armage in the comments) and using them in views is common and definitely accepted .

This is of course all my opinion formed from years trying to keep content separate and in the right place, your mileage may vary.

Answer 3

If it’s for manipulating how data is presented, then it should sit in a layer between the controller and the view. Your controller should fetch data from models, and your view should display that data. Your view could be anything: HTML, PDF, CSV, JSON etc.

Have a look at view presenters. They take an entity and prepares its data for presenting in a view. Therefore, your view presenter class could have a method called priceFormatted() that returns the price value formatting with decimal places, thousands separator, currency symbols etc. This way, you could use your presenter methods in your HTML view, but for other views (i.e. XML or JSON) you could just use the raw value.