tags:

views:

123

answers:

4

I've recently started to rewrite a project I did a few years ago using CakePHP. I'm trying to do everything 'right' this time, so maybe someone get give me a a pointer on doing to the following:

I'm showing a simple table from a table using Model->find('all') in the View. There are two boolean fields in this table, that together make up something I need to show to a user. So: 0x0 = 'A', 1x0 = 'B', 0x1 = 'C', 1x1 = 'D'. Where should I put this logic? I've been thinking about the following methods:

  1. The view
  2. A View helper
  3. The controller
  4. Something in the Model so that Model->find('all') outputs this value (is that even possible?)

This task might seem trivial, but I think it might learn me getting this project organized and maintainable from the start.

Thanks!

A: 

In the controller! The methods from the model comes in the controller. The view is just for output( like HTML UI programming.)

poo
The controller is really the worst place for this. It's reponsiblity is only to handle Requests. You want thin controllers and fat models.
Gordon
YES in the model should the business logic be.
poo
+1  A: 

If it's something you're going to use all over the place I would put it in the model. You can either put a method on the model that gives that value back or loop over all the rows you've retrieved in an afterFind callback and set it as a proper field.

grapefrukt
+5  A: 

Well, it depends on the type of logic for making up final table (is it presentation or business?).

Imagine you add new type of UI, for example command line interface. How would you show your table there? The data passed to View has to be same for both HTML and console presentations. So the logic which is responsible for preparing that data - is business logic and it should be placed in Model. The logic responsible for displaying the data should be placed in View (maybe in view helper if it's used more than once).

And never place this kind of logic in Controller.

Qwerty
I agree. If this is something that only relates to how the table is rendered, place it into a ViewHelper. But if this is an information pertaining to the model state, place it in the model, give each combinatory state a name and access it through a getter.
Gordon
Agree as well. I would place this in the afterFind callback to have a nice DRY support
harpax
A: 

I put this kind of logic in the view if it is something that is going to determine rendering style. In that way, the designer has maximum access and can style accordingly.

On the other hand, if the two columns only exist for convenience in datamodelling, put it in the model. The designer shouldn't even be aware of other possibilities!

Leo