Controller or View [closed] - php

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have always coded controllers so that they simply call data from a model and then present that data to the view:
class ProjectViewModel
{
public $User = NULL; // Contains authentication levels etc
public $Projects = NULL;
}
class ProjectController
{
//...
public function ListProjects()
{
$viewModel = new ProjectViewModel();
$viewModel->User = $this->sessionRepository->GetSession();
$viewModel->Projects = $this->projectRepository->Projects();
return View::make( "ViewName", $viewModel );
}
}
Now in my view:
<ul>
<?php foreach( $Model->Projects as $project ) { ?>
<li>
<?=$project->Title?>
<?php
switch( $Model->User->Authentication->Type )
{
case AuthenticationType::ADMIN:
| <button>Edit</button>
break;
}
?>
</li>
<?php } ?>
</ul>
You see in my way of doing things, the person designing the view decides what is shown based off of the user's authentication... Don't take this just for how I have made it too, you can think about the model returning projects with a property that states whether they can or cannot edit a specific project... The main idea is there is 1 Boolean value that states if someone can or cannot do something to a project.
My colleague has gone for a different approach, which is interesting because he is defining within the controller, if a "button" (which may or may not exist if the view person decides to show it in a different way) should be shown or not:
class ProjectController
{
//...
public function ListProjects()
{
$viewModel = new ProjectViewModel();
$viewModel->User = $this->sessionRepository->GetSession();
$viewModel->Projects = $this->projectRepository->Projects();
$viewModel->Buttons = array(
"EditButton" => array(
"Name" => "Edit button",
"Show" => ( $viewModel->User == AuthenticationType::ADMIN ) ? TRUE : FALSE
),
"OpenProjectReportButton" => array(
"Name" => "Open project report",
"Show" => ( $viewModel->User == AuthenticationType::ADMIN ) ? TRUE : FALSE
)
);
return View::make( "ViewName", $viewModel );
}
}
In the view he uses buttons that have been pre-declared in the controller:
<ul>
<?php foreach( $Model->Projects as $project ) { ?>
<li>
<?=$project->Title?>
<?php if( $project[ "EditButton" ][ "Show" ] ) { ?>
<button><?$project[ "EditButton" ][ "Name" ]?></button>
<?php } ?>
</li>
<?php } ?>
</ul>
Although I understand why he might think this is a good idea, The controller is now taking on some of the work of the view... In fact he has gone as far as to say that the view will have buttons.. which the designer may disagree with...
It also means that if the view guy wants to add another button somewhere else, he's going to have to ask the controller guy to give him a new button in the array for something else... and just after doing that, he may then say, actually it's not a button, I just want to show an image instead...
Am I right in thinking this is wrong?
Overview:
A controller should fetch data from the model, and push it to the view for the view to display it how it wants to display it...
A view should use that data to decide how and what to show on the view... ( further more to this, if you are worried that an admin button is shown accidently, if they click on that button provided by the view engineer, it doesn't matter.. the user get's taken to another page which loads a controller which insists that actually, this user does not have access to this page... )
The view guy should be asking questions like, can this user edit projects... rather than have I been given a button that I can display to the view
What if the view guy decided actually, for design purposes, I want to show buttons that the user can't use... and provide a message stating why he can't use it... The controller in my colleagues example has provided a list of buttons that will now have to be ignored considering the view engineer (artist/designer) is decided actually, screw your controller... I want to show that button!
Am I right?
EDIT:: I've added new tags because i'm aware that PHP and C# people have very different approaches to problems... and i'm interested in the view from asp.net users aswell.

Answer 1

Proper MVC separation is simply only about separating responsibilities appropriately:
the model does all the work, everything your application "can do" is part of a thick model layer
the view visualises the state of the model, i.e. what's going on in your app, to the user (or to other entities)
the controller mostly just reacts to events (input) and directs them to appropriate actions to make something happen in the model and refresh the view if necessary; it's the plumbing between model, view and the rest of the world
As such, it's none of the controller's business to do anything which has to do with presentation. The view is also not simply a single .php HTML template. The view can be as thick as the model layer and its responsibility is to do anything that's necessary to produce useful output. The view should directly talk to the model to get the state information it needs as appropriate. Pretty much all of the code that's currently in your controller belongs into the view.

Answer 2

A couple of things, first expanding on what deceze said:
"Pretty much all of the code that's currently in your controller
belongs into the view"
I agree, your controller is junked up with stuff that shouldn't be there. Your controller should look like this:
class ProjectController
{
public function ListProjects()
{
return View::make("ViewName");
}
}
The data preparation works better inside Laravel's ViewComposers.
In Laravel they have a construct called the ViewComposer. It is designed to prepare data for your views.
You specify a class called:
class ViewNameComposer {
public function compose($view){
$view->model = new ProjectViewModel();
$view->model->User = $this->sessionRepository->GetSession();
$view->model->Projects = $this->projectRepository->Projects();
}
}
And then you register it with the view:
View::composer('ViewName', 'ViewNameComposer');
And when that view is rendered the composer hooks in and prepares the data for the view.
What is really awesome is that you can associate ViewComposer with partial view snippets.
This means that when you are using say the Blade templating engine and your page view has a boolean that determines whether or not to display some "other content", if you save that "other content" as a partial view snippet and conditionally include it
#if($someBool)
#include ('partials.ViewName.othercontent')
#endif
then you can only load the data that the partials.ViewName.othercontent needs (from the ViewComposer of partials.ViewName.othercontent) if it needs it.
What I like about this approach is it helps keep the views a bit cleaner and it gets rid of the junk that shouldn't be in the controller.
For more information on ViewComposers check out their documentation:
http://laravel.com/docs/responses#view-composers