Putting the View back into MVC.

[eluser]Pygon[/eluser]
I'd like to open a bit of a discussion on something that's always bothered me (slightly).

As I review and write code based on what I know of the MVC design pattern, I find myself slightly confused as to what the "correct" way to implement this is, versus the way of CI. The majority of this confusion is centered around the Controller/View relationship and View logic.

It seems to me that in the majority of cases, the Controller is being used to determine which view will be displayed, what data the view will receive and so on. From my (possibly limited) understanding of the MVC pattern, the view should make its own determination as to what to display and what data to obtain, which means the View should have a logical layer all it's own (similar to the controller but with the goal of displaying content).

Any thoughts?

[eluser]dtrenz[/eluser]
Model: DB logic | Queries and DB operations and such
View: Presentation logic | Markup with minimal amount of code for control structures and such
Controller: Business logic | Massage the data retrieved from the Model; stage the data for the presentation layer (view).

That's my take, anyway.

[eluser]Michael Wales[/eluser]
I'm trying to figure out what my Controllers would do, if there was another layer for view logic...

[eluser]xwero[/eluser]
After reading the blog post found in this topic i began to wonder myself. And to my understanding would it more MVC correct that the model calls for extracting data are best handled by an observer and not by the controller that assigns the view(s) to the url. Like you say the view should have it's own logical layer.

Now for the question how to make this possible in CI? maybe the Khaos :: Event Manager can be a solution? Or if you want CI to have this functionality a check could be made in the loader class if there is an observer with the same name as the view to add the data.

pseudo code

Code:

// in the loader view function
if(file_exists(APPPATH.'/observers/'.$view.EXT))
{
   include(APPPATH.'/observers/'.$view.EXT);
   $this->load->observer($view);
   $this->viewdata = $this->observer->data();
   unset($data);
}
// observer for view.php
class View_observer extends Observer
{
   function View_observer()
   {
      parent::Observer();
   }

   function index() // default
   {
      $this->load->model('somemodel');
      return $this->somemodel->method();
   }

   function update() // called using the first parameter of the observer data method
   {
       $this->load->model('somemodel');
      return $this->somemodel->othermethod();
   }
}

It's an idea i don't know if it makes much sense.

[eluser]xwero[/eluser]
[quote author="Michael Wales" date="1205351009"]I'm trying to figure out what my Controllers would do, if there was another layer for view logic...[/quote]
The controllers would take care of the data altering model methods and the assignment of the views.

[eluser]MadZad[/eluser]
Pygon,
First off, I'm sure you'll find that such mvc opinions are like snowflakes...

For my part, I started by writing all-in-one programs. First split off the view portion about '98, and declared it to be a very good thing. Found splitting model from controller to be needlessly annoying and resisted (or sometimes just didn't need) for years, but did come around and sorry I didn't embrace it sooner.

As with all things, it depends. What is your preference and who else is going to have to work with the code you write? How complex is your code? (short and kludgey is fine, but if it grows, un-kludge it) Will non-programmers be contributing to the view? (in my utopia, I provide the view's header/footer, a very simple data structure the screen needs, and a description of the functionality. then an html/css/graphic guru who isn't intimidated by code but won't write any - they implement the view)

My stock answer is to embrace MVC more, and I find CI helps me do just that. I try to keep all DB access in the model, all business logic in the controller, and the only code in the view is for making display decisions. This helps me and others to understand the code more quickly - and that leads to shorter bughunts (single most time consuming part of the dev process, imho) and quicker implementation of requirements changes. I've been known to have stakeholders that change their minds at the most inconvenient times - but I'm sure that's a unique experience. :cheese:

When logic starts creeping into the view, down the road this can lead to confusion if you expect to make business logic updates in the controller. Sure, logic will creep in, but recognizing when to refactor and move it to the controller (or in CI's case, perhaps extend a library or create a helper) is where wisdom and experience come into play.

So, generic advice is to aim for low coupling - the M, V and C, while dependent upon each other, should have contained functionality. Any of them should be easily readable and accomplish only what they need to.

Some advice from my uncle, who rightly taunted me for buying a combination string trimmer / leaf vacuum.

One tool, one job. You get a tool that does two jobs, and it'll do both poorly.

Edit: holy crap - there were no replies when I started typing and I'm the 5th reply. What a community!

[eluser]xwero[/eluser]
Thinking more about it. It would remove one line in many of the methods i have written so i don't know if it should be abstracted? But it could be useful in methods where adding,updating and deleting is present.

[eluser]dtrenz[/eluser]
[quote author="MadZad" date="1205351932"]Pygon,
My stock answer is to embrace MVC more, and I find CI helps me do just that. I try to keep all DB access in the model, all business logic in the controller, and the only code in the view is for making display decisions. This helps me and others to understand the code more quickly - and that leads to shorter bughunts (single most time consuming part of the dev process, imho) and quicker implementation of requirements changes. I've been known to have stakeholders that change their minds at the most inconvenient times - but I'm sure that's a unique experience. :cheese:

When logic starts creeping into the view, down the road this can lead to confusion if you expect to make business logic updates in the controller. Sure, logic will creep in, but recognizing when to refactor and move it to the controller (or in CI's case, perhaps extend a library or create a helper) is where wisdom and experience come into play.[/quote]


Couldn't have said it better.

[eluser]Pygon[/eluser]
--Edit topic exploded while i was typing/working, will post followups--

My take is a bit different dtrenz.

Model: Object / Data accessor and storage. Has no awareness of what controller/view is making a request, just does what it is asked.
Controller: Invokes changes in the model based on user nav/input/submit/etc (tells model to update with the new information); Invokes proper view structure.
View: Logical Presentation based on structure invoked. Requests data from model and formats data for presentation. Has no awareness of the controller who called it, just does it's display.

Atleast, that's my take from all that I've read on MVC.

MW:
Controller would do many things in response to the users input, it just wouldn't be gathering and formatting data for the view, it would simply tell the view what data it should gather and format.

[eluser]xwero[/eluser]
the MVC take where wiredesignz made me aware of, http://www.phpwact.org/pattern/model_view_controller , has a slightly different view as i understand it:

If you have a passive model the data requests happen in the controller and if you have an active model the data requests happen by observers.