Views best practices

[eluser]JasonSTX[/eluser]
ok, which is better:

Option 1.
Controller calls Model and Model returns list of logged in users
Controller adds user list to $data array
Controller calls View and View parses out the $data array and displays users

or
Option 2.
Controller calls View
View calls Model and Model returns list of logged in users
View parses out the returned array and display users

I just keep thinking that in a templating environment, I don't want to have to keep sending info to the view, for default information (menu's, user lists, etc.) the view should be doing all the work.

Am I on the right track? Relatively new to MVC.

[eluser]ejangi[/eluser]
In an MVC paradigm Option 1 is correct.

What you could do though, is create a plugin or helper to give you a list of logged in users:

Code:

function get_user_list {
    $CI =& get_instance();
    $CI->load->model('users');
    return $CI->users->get_user_list();
}

Always remember that while MVC may seem like you're doing things the long way round, ultimately it's MUCH easier to maintain and once you get the hang of it, it becomes a lot smarter and more sensical! ;-)

[eluser]gtech[/eluser]
[edit]My opinion has changed since I wrote this reply[/edit]

Personally I use option 1, I try to separate the model code from the view. The controller manages the loading of models and may make changes depending on the parameters passed in and then loads the appropriate view. the view can then concentrate on displaying the data and not have to worry about complex code logic. This means a designer can focus on making the page look pretty without having to get bogged down in code.

Sometimes I want to update the page using javascript say to alter the content of a div without refreshing or redirecting the page.. In this case I may use jquery (javascript module) to make a request to controller from the view which will then call the appropriate models and display html content generated by the view inside the div seamlessly without refreshing.

this is my take on it, other people may differ and there is nothing stopping you from calling a model within a view.

[url="http://en.wikipedia.org/wiki/Model-view-controller"][here is wikipedias take on it] [/url] its a nice simple explanaton.

[eluser]JasonSTX[/eluser]
My personal inclination is to put all the logical processes into the model and then call it from the view.

It just seems much longer the other way like you were saying. Lets say I have these different blocks of information
Logged in Users
Last Registered Users
Last 10 Posts

Option 1 means that I am doing this

$data['loggedinusers']=$this->SomeModel->getloggedinusers();
$data['lastregisteredusers']=$this->SomeModel->getlastregisteredusers();
$data['last10posts']=$this->SomeModel->getlasttenposts();
$this->load->view('showall',$data);

That loads the showall view and it then parses all the array data and displays it.

The long part (to me) is that lets say I want to add a new block of information called Server Stats. I have to update the showall view, then update every single controller to add: $data['serverstatus']=$this->SomeModel->getserverstatus();

But with Option 2, all I do is add the model, then add a section to the view and it shows up on every page.

The wikipedia article seems to lead to option 2.
"A view uses the model (indirectly) to generate an appropriate user interface (e.g., the view produces a screen listing the shopping cart contents). The view gets its own data from the model. The model has no direct knowledge of the view."

So the view wouldn't directly interface with the model (like updating a users shopping cart from the view) but it would indirectly (show me the users shopping cart).

Is that correct?

[eluser]gtech[/eluser]
you do have a point, in your instance it sounds as if you have many controllers accessing a view and with your design it seems easier in the view to retrieve the information directly from the model (luckily CI is flexible enough to do this), I dont think this is a wrong approach at all. [edit] you may have to be careful about maintainability.

My controllers tend to be more database centric (eg. my cusomter controller has functions that list all customers, groups, adds, edits and deletes them) I usually have one controller calling one view (except the header and footer views), and so opt1 makes more sense to me.

[url="http://ellislab.com/forums/viewthread/65632/"]see previous discussions[/url]

[edit]
P.S reading a bit more.. in MVC views AND controllers can retrieve data from the model but a view should not be able to make changes to the model.

[eluser]JasonSTX[/eluser]
[quote author="gtech" date="1196922667"]
P.S reading a bit more.. in MVC views and controllers can retrieve data from the model but a view should not be able to make changes to the model.[/quote]

Exactly what I was thinking. Simple stuff, viewing not modifying, is fine via a view. Data manipulation isn't.

The last post on that thread lays out what I was thinking pretty well.

I will give it a try this way but if it doesn't work I don't see that big of a problem switching things back. Heck, I can just create an array and a foreach if I need to in each controller to load whatever models I want to send to a view

Thanks for the responses, I think I have a decent grasp on it now.

[eluser]gtech[/eluser]
cool, I have learned something as well .

[eluser]matthewr[/eluser]
Yup Option 1 is the way to go. Controllers should be the one to access models. Views are just for displaying content

[eluser]nmweb[/eluser]
[quote author="matthewr" date="1206314030"]Yup Option 1 is the way to go. Controllers should be the one to access models. Views are just for displaying content [/quote]
And views can continue to just display content when they retrieve information from the model. Only data changing operations are forbidden for the view, the controller can do those. There's nothing wrong with data retrieval by the view. It even saves quite some code if you do it right.

[eluser]wiredesignz[/eluser]
Absolutely as nmweb says, Views should retrieve data from the Model. It follows the MVC design pattern more closely. Plus consider the following:

Option 1:
The Model has a copy of the resultset. (2 copies if you count the Database Driver result)
The Controller has a second copy of the resultset.
The View has a third copy of the resultset.

Option 2:
Only the Model contains the resultset.
The View iterates the resultset in the Model.