Putting the View back into MVC.

[eluser]adamp1[/eluser]
Well I believe that's the answer, hit the nail on the head 100%.

[eluser]xwero[/eluser]
And now to answer your own question Pygon

How SHOULD CI handle this to be more in line with the MVC pattern

[eluser]Pygon[/eluser]
And don't get me wrong -- I also had this discussion with Neophyte;

I believe the CodeIgniter, the AMAZING framework that it is, can do ANYTHING anyone wants with a little work. I also agree that the approach that they have taken to Views isn't bad in the least -- as you can tell just about anyone can hop into it and make something useful in MVC of sorts (course, there will be deeper issues with reusability probably but that's a different discussion).

[eluser]xwero[/eluser]
It wasn't a question to drag you out of your hole, i made the remark to know how you would like to see CI evolve in the future. Must CI take steps to be more true to the MVC pattern to be your framework of choice?

[eluser]Pygon[/eluser]
No I understand xwero -- was just a comment -- but yes I think it should (atleast for me).

I much prefer the idea of a view object that has methods for loading files / rendering output etc. I find this would be far, far easier to extend to use templating systems, and to be able to contain more coherent logic than the procedural php of current view files. I also think that this would allow you to group similar views that may have the same general layout -- ala:

Code:

class View_Comments extends View_Layout {
  
   function View_Comments($method){
       parent::View_Layout();
       $data['body'] = $this->{strtolower($method)}();
       $this->render($data);
   }

   //Individual functions
   function success(){
       ###Get Data from Model and ###
       $mydata['message'] = $this->lang->line('comment_success');
       $mydata['comments'] = $this->comments->get();
       return $this->loadView('comment_success.tpl',$mydata);
   }

   function error(){
       //like the above
   }

}

Like I said though, it's pretty much all subjective but this would be my preference.

[eluser]fdog[/eluser]
@Pygon:
That would be easily implemented with PHP5 (OOP). I think CI does an excellent job handling MVC taking into consideration there is no clean OOP involved in the process.
As a hardcore Python developer, I love OOP, but some people within the CI community might feel alienated if CI took this approach (I'm just guessing).

[eluser]Pygon[/eluser]
[quote author="fdog" date="1205527592"]@Pygon:
That would be easily implemented with PHP5 (OOP). I think CI does an excellent job handling MVC taking into consideration there is no clean OOP involved in the process.
As a hardcore Python developer, I love OOP, but some people within the CI community might feel alienated if CI took this approach (I'm just guessing).[/quote]

I agree -- like I said, CI can do anything. I could easily extend the loader so that view() uses the same type of loader as load->model and go to town.

I disagree with the thought that people would feel alienated. If anything, it adds flexibility (a designer would have to deal with no different code than the current setup) but the view flow is moved out of the controller where it doesn't belong. Also, considering that people are already required to use OOP for models, controllers and everything else, I don't see why they would feel any different about the view.

[eluser]mradlmaier[/eluser]
Hi all,

I haven`t read through all the post about this, but in think one aspect to keep in mind is the deeper reasons why we use MVC in practical terms. Then it becomes a bit more clear what to put where, why and when. We don`t use it, just because it is cool to do so. We use because it, because we want to achieve minimal coupling of parts of our application.
For examples, the real advantage of separating the model (your application data) is, that instead of a relational database you one day could decide to store your application`s data in a flat file. So if you have correctly separated your controller from your model, you should be able to do this without changing anything in the controller. There should be a clearly defined interface between controller and model. The same goes for the view and the controller.
So, the way i decide which goes where, is simply to try to imagine if things still work, if the model or the view or the controller is exchanged by a different implementation. If i can do that without breaking the whole thing, then everything should be in the right place / makes sense.
In the end, a developers job is not to 'correctly' design an application, but to deliver an application with minimal effort, while maintaining a high degree of agility, if costumers requirements change.
So any design pattern should not be seen as a 'religion', but just a tool to get the job done.

Michael