Putting the View back into MVC.

[eluser]xwero[/eluser]
[quote author="dtrenz" date="1205355802"]I'm no MVC expert, but it appears to me that CI adheres correctly to the basic principals of MVC. In most of the writings on MVC I've seen, the view only accesses the model indirectly via the controller.[/quote]
I think it doesn't mean that because the dashed arrow from model to the view doesn't pass the controller.

For the question if is this the right path? CI wants to be a framework for small applications and big big applications so i think the MVC interpretation of CI is a good compromise.

[eluser]MadZad[/eluser]

It seems to me that people are constantly looking for even more ways to seperate their structure

For clarity, yes - if you deem it worthwhile. For the sake of separation, no - but I've certainly caught myself doing so. Too much separation can be unreadable to the point of hindrance, of course.

What it really comes down to is identifying chunks of code that perform one function and put them somewhere appropriate. That way my business logic can be easily read, which helps me develop and maintain:

Code:

function take_action() {
  if (!userIsAdmin()) {
    showNoAccessAndQuit();
  }
  //now I actually do the action
}

Simplistic example, but now when I look at my controller, my mind doesn't have to be distracted with the DB, session or redirects. Based on how I think it would work best, those 2 helper functions (clearly could be one) could be in the same controller (prefixed with an underscore, of course) if only that controller needs them, or a helper/library/other if another controller would use them.

There is an added benefit to separating out chunks of logic - unit testing. If you have some kind of automated/easy regression testing, your productivity can increase while your bugcount decreases. As with all things, your mileage may vary.

[eluser]MadZad[/eluser]

CI wants to be a framework for small applications and big big applications so i think the MVC interpretation of CI is a good compromise.

Ding, ding, ding! One of the reasons we chose CI is because you can use MVC, or do whatever else you want - and that attitude is pervasive in CI. Want more MVC discipline - then do it, or perhaps another framework is a better choice, and sometimes that is optimal. Need less discipline - hey, you could have no models, 1-line controllers and have a perfectly functional application using CI. You won't catch me saying that's inherently wrong (suppressing my opinion, well that's tougher).

[eluser]Michael Wales[/eluser]
Yeah - I definitely think discussions like this are great. It's always nice to get really smart people together and challenge one another's assumptions, or challenge and push the framework to levels we have yet to see.

But, in this particular case, I think the "CI way" is a beautiful thing. I can implement my strong models that handle the data based on what "type" of view the controller is calling. Pygon, you can implement observers if you'd like. Someone else could completely omit the model.

It's a beautiful thing.

[eluser]wiredesignz[/eluser]
The strange thing to me is that most CI example code suggests collecting your model resultset in an array and passing this to your view. Not only does this place more demand on memory, but breaks the basic MVC principle of seperation of concerns.

It seems more fuctional to fully prepare the data for display while its still in the Model and then pass only a reference to the Model into the View.

The View remains independent of the Model, the reference can be changed at any time by pointing to a different Model as needed, and the View processing is simplified.

EDIT:
On a second reading I can say quite categorically, Pygon and xwero have the MVC design pattern correct, Controllers are not supposed to gather data or manage business logic.

Each component must be reusable, the Model goes with its data source and doesnt care about the Controller or the View, the View needs a data source, but it doesnt depend on one exact Model, any Model providing the correct data could be used. The Controller should not depend on either the View or the Model.

[eluser]pjturpeau[/eluser]
[quote author="wiredesignz" date="1205383488"]Each component must be reusable, the Model goes with its data source and doesnt care about the Controller or the View, the View needs a data source, but it doesnt depend on one exact Model, any Model providing the correct data could be used. The Controller should not depend on either the View or the Model.[/quote]

But in fact, a controller reacts to the user interactions performed through the view. The way these interactions are performed is tightly coupled to the view itself (list, buttons, etc, or the way you structure you form in a web app). Unless you add a special "interaction controller" between the View and the Controller which could transform the "structural" interactions into "functional/business" ones, it seems to me that the controller is always coupled to the view.

[eluser]xwero[/eluser]
As i see it the model must be the most reusable component of the application structure which means it should only return data. In another thread i have a discussion with nmweb where to put the rules of the validation if the validation is done in the model. The biggest issue for me is independence from the view because the model should be used by other views with other fields.
So if you want to do it good there would have to be an observer between the post and the data altering model method for the validation and an observer between the data extracting model and the view to prepare the data. I think that way you have the best separation possible making the components as reusable as possible. It are the observers that do the dirty work.

A quick and dirty example

Code:

// controller
function somepage()
{
   if(count($_POST) > 0)
   {
      list($action,$error) = $this->view_actions->evaluate();
      switch($action)
      {
           case 'add': // stay on the same page
             $this->view_build->do($error);
             break;
           case 'update': // go to another page
             if($error != '')
             {
                $this->view_build->do($error);
             }
             else
             {
                $this->otherview_build->do();
             }
             break;
           case 'delete':
             $this->view_build->do($error); // if there is an error the view will display the posted data instead of the model data
             break;
      }
   }
   else
   {
      $this->view_build->do(); // the function will load the views/view.php file with the model data
   }
}

It can create a lot of additional files but it's called separation for a reason

[eluser]xwero[/eluser]
[quote author="pjturpeau" date="1205409978"][quote author="wiredesignz" date="1205383488"]Each component must be reusable, the Model goes with its data source and doesnt care about the Controller or the View, the View needs a data source, but it doesnt depend on one exact Model, any Model providing the correct data could be used. The Controller should not depend on either the View or the Model.[/quote]

But in fact, a controller reacts to the user interactions performed through the view. The way these interactions are performed is tightly coupled to the view itself (list, buttons, etc, or the way you structure you form in a web app). Unless you add a special "interaction controller" between the View and the Controller which could transform the "structural" interactions into "functional/business" ones, it seems to me that the controller is always coupled to the view.[/quote]
It doesn't need to be. for example

Code:

function page()
{
   $view = $this->uri->segment(3);
   if($this->validation->view_available($view)) // custom validation
   {
      $this->load->view($view);
      // alternative
      // $this->build_view->do($view);
   }
   else
   {
      redirect('');
   }
}

The view is only coupled with the controller by the url. The controller only intercepts the request of the user. You could make the coupling looser by creating a class that loads the data and other view requirements (see alternative in the example).
But you are right that most controller are tightly coupled with the views in most cases and examples.

[eluser]wiredesignz[/eluser]
[quote author="pjturpeau" date="1205409978"]But in fact, a controller reacts to the user interactions performed through the view. ... it seems to me that the controller is always coupled to the view.[/quote]

Absolutely not, the controller reacts to the request URI information and maybe some persisted application state. It does not matter wether the request comes from a view or any other source.

[eluser]zilverdistel[/eluser]
[quote author="wiredesignz" date="1205420616"][quote author="pjturpeau" date="1205409978"]But in fact, a controller reacts to the user interactions performed through the view. ... it seems to me that the controller is always coupled to the view.[/quote]

Absolutely not, the controller reacts to the request URI information and maybe some persisted application state. It does not matter wether the request comes from a view or any other source.[/quote]

Well that is true, the controller reacts to the request URI info. But let's not forget this is just a choice of how to implement the interaction. There might be other choices. But on the level of design _patterns_, this really doesn't matter. The URI is still just a way for the user to interact with the system. And although it might be possible to interact, only by way of URI's (and sometimes we do, eg Googlemaps API, picasaweb API ...), but basically, in CI, the user wants a view, from which he/she can point to a specific controller method.