What to put in a view?

[eluser]lkagan[/eluser]
I'm just curious about how much logic, if any, you all place in your views. For example, I think it's OK to format a phone number in a view. If the number is stored in the DB as 9999999999, then writing a little logic to format that in the view seems fine to me.

At what point do you draw the line?

Thanks.

[eluser]Pygon[/eluser]
To me it depends on how you would look at the scope of "view".

View -- meaning the entire presentation, including formatting, styling, and so on.
--or--
CI's View model -- more closely related to a "template".

View (proper) would include all code related to the presentation, formatting, etc. of data recieved from a model. A model should never understand, or care, how a view would like to recieve the data (date formatting, number formatting, etc). This ofcourse would be to the letter of MVC design. The real world isn't usually that easy.

[eluser]Chris J Smith[/eluser]
Chuck any reusable formatting stuff in a helper and use that as it aids consistency.

The controller, for purists, should only provide the mapping between the object model and the user interface, and encompass any multi-step business rules.

If you think through a problem first, it can always be resolved without the need for hacks.

[eluser]maadmac[/eluser]
[quote author="lkagan" date="1193710692"]At what point do you draw the line?[/quote]

It's up to you, really. The code of even an MVC 'purist' is bound to contain some overlap somewhere, which reflects that developer's particular bias. MVC for me is like Pirates of the Carribbean: more guidelines than actual rules.

The short answer is, if you can manage to contain all the logic in the controller, do so, since its job is to be traffic cop. Neither the model nor the view should care where the data are going or where they're coming from, respectively... but there are times when it makes more sense in that moment to put it in the view.

Here's how I use it: if it's less effort for you to put code in one place than it would be to change it later, then go for it. Remember, MVC is a design pattern that is supposed to make your life easier; it's supposed to allow you to accomplish the same thing with less coding. If it requires substantially more coding to maintain strict MVC, then in my mind it defeats the purpose. For small apps I won't even use models, I'll query the db from the controller -- it would just be silly otherwise.

Separating all of the components helps you track down what you're looking for when something goes wrong, or makes it easier to change something fundamental later. But sometimes you don't have complex needs, or you don't need to much changing, in which case I find applying MVC strictly takes more effort than it saves. That's my real guideline.

[eluser]Jim OHalloran[/eluser]
[quote author="Pygon" date="1193711183"]View (proper) would include all code related to the presentation, formatting, etc. of data recieved from a model. A model should never understand, or care, how a view would like to recieve the data (date formatting, number formatting, etc).[/quote]

That's exactly how I manage my views. Controllers/Models supply views with standard data types and the view needs to format those to as required. e.g. dates are passed to views as a Unix timestamp, it's up to the view to format that into a human readbale form.

I pack everything that's styling/formatting/display related into views. You know you've gone too far though when you start wishing for database access in the view.

Jim.