MVC - a question about the relevance of controllers

Hi all,

I am trying to create a PHP/MVC application without the help of a framework. When I start to do some serious development in PHP I may use a framework, but before that I thought it would be a good idea to gain an understanding of the principles of MVC.


Suppose I have a page WidgetView.php containing the following code

Code:

---

<ul>
<?php 
  $cList = new Widgets();
  for($j= 0; $j < $cList->count(); ++$j) {
          $c = $cList->item($j);
                  print '<li>'.$c->getName().
                  ' <a href= /"index.php?route=widget/edit&amp;widget_id=/"'
              .$c->getID().'>edit</a></li>';   
    }

?>
</ul>

---

This page simply lists the names of widgets (fetched from the database table) and displays a link to edit an individual widget item.

Now, clicking the "edit" link invokes the controller and the controller in turn serves up EditWidget_View.

My question is : Why shouldn't the edit link directly invoke EditWidget_View ? The controller takes the input parameters from WidgetView and passes them on to EditWidget_View without any processing of any sort, it's merely functioning as a postman here. What is the practical use of routing the edit action through the controller ?


Pardon me if the question sounds stupid. I hope someone here can help me.

Thanks

Crusoe

Moved From The CodeBank (which is for sharing code rather than asking questions. :)

Ah, I didn't realise I had posted it in the codebank. Sorry :)

because you could have multiple views... your controller determines (or should be) what views are to be loaded.

considering a practical example... I'm re-writing my website using the MVC model provided by CodeIgniter. Each single page consists of multiple views: Header, QuickLinks, a sub-header, content, side bar navigation, and a footer. The header and footer never change... they are fairly static, but I made them their own views so that if I need to, I can customize each one per controller.

So now my controller has let's say three potential views (in reality it's 8, but for simplicity, I'll address 3)... 1) The default view 2) recent news (which can be linked from the Quick Links and the SideNavigation) and 3) Featured (which is only linked from the side bar).

Each view is a PART of the whole web page... and cannot stand on it's own (well, it could, but it wouldn't look right). One of the advantages of having the controller is that you can load multiple views. I've done this so that I have ONE header... if I change my _header_view file... then it updates the whole site.

Each one of the methods in my controller does the same action:
1) Header
2) Quicklinks
3) Content - default content; recent news content; featured content
4) Sidebar nav
5) Footer

I've got it setup in the controller so that the name of the requested view is also passed to QuickLinks and the SideBarNave views... that allows me to turn off selected links (specifically the ones that point to the page the visitor is actually on). Featured is only in the SidebarNav... while Recent News is in both the QuickLinks and SidebarNav views.

This gives me an advantage that I could simply change one file in the SideBarNav and it replicates through the whole site... same for each of the views... now all I need to maintain is just the different content views...

I guess it's a long way of saying that a controller could potentially server up more than one view.

Is this helping any?

-tg

Also... technically, your view is flawed.... your controller should be getting the list of widgets (the model) and passing that to the View.... the view should then simply loop through the list...

in other words:
$cList = new Widgets();
should be in your controller.... and passed in.


then upon clicking the edit link, your controller should be loading up the data about the widget and passing all of that to the view... if your view is getting data from anywhere other than what's passed from the controller, there's a flaw in your design.

-tg

Hi TG,
Thanks for answering. The sample code I posted is a rough approximation of a view to convey the idea.


Yes, I am 100% convinced by :

Quote:

---

Originally Posted by techgnome

One of the advantages of having the controller is that you can load multiple views.

---

I never thought of that angle, I guess it comes from inexperience :blush:

Many thanks once again.

Regards

Crusoe

Hey we're all learning... I've been using MVC for all of 4 hours ... which is how long it took me to install CodeIgnighter, watch 4 videos on the basics of CI... and then take my current development site and re-build it suing the CI MVC framework... So far I've only gotten the VC part of it going... tonight I plan to start getting some of the models set up.

Although, I do admit, I hit a snag where my AJAX no longer works on the site... but I saw a video tutorial for using AJAX, so I may watch that tonight and see if I can get that part working... then deal with the model bits... just depends on which I feel like tackling first.


One of the fallacies I keep seeing when it comes to MVC tutorials (and even the CI one does this) is they tend to tread the view as the whole page... rather than what it is: a view of a particular piece of data... very few of us build websites (or applications in general) that consist of a single entity... there's usually several view components on the page. Like my page: Header View, QuickLinks View, SideBar View, Footer View and the ever changing Content view... I even have a couple cases where the content view actually has two views... the primary content for that view as well as including the featured view...

It's all neat stuff... once I got my head around the concepts, and playing with the code, I could see the potential... and I get why it's so popular... and the fact that it's so freakishly easy to set up (as long as you have a base framework to start with.... I shudder to think what it would have taken had I tried to build something like CI myself... I'm good... jsut not THAT good.)

-tg

Quote:

---

Originally Posted by Crusoe

When I start to do some serious development in PHP I may use a framework, but before that I thought it would be a good idea to gain an understanding of the principles of MVC.

---

Personally, I'd think that using a framework would be advantageous in helping you gain an understanding of the principles of MVC. I am new to MVC and am having to use CakePHP; while I'm not sure how much I like it, the pre-set setup seems to make sense and is helpful for understanding the concepts.

I agree with Samba there... CI has gone a long way into helping me understand MVC ... since the plumbing is already built... it frees you up to concentrate on the principles... later if you're feeling gutsy and want to implement your own framework, at least you'll have the concepts down pat, making it easier to design and build the FW. If you try to deal with the plumbing now, you'll get bogged down in details that will just frustrate you and result in exasperation with MVC.

-tg

Quote:

---

Originally Posted by techgnome

... rather than what it is: a view of a particular piece of data ...

---

Yes very much so. A controller that builds a composite view from many smaller views makes perfect sense to me. Now, things are slowly beginning to fall into place :D

BTW, how do you rate CI against Prado ?

Don't know anything about Prado... that's the first I've heard of it (or CakePHP for that matter) ... for me, CI seems to be just what I need... highly customizable, easy to install, and as I mentioned in less than 4 hours I nearly completely re-built my website... and got the same functionality that had taken me 2 days to construct from scratch. I've never had that kind of productivity (on building a website) before when starting with next to nothing. And the first two hours were watching the videos and following along with code on my machine. Maybe when I'm done with this incarnation of my site, I'll give the others a try and see how they compare. I do know that CI is fairly widely used - that's how I came across it... saw it mentioned in a couple of places. -- I'd do some comparison now, but I'm "in the zone" with construction and I could see myself easily distracted and never getting back to my main goal.

"A controller that builds a composite view from many smaller views makes perfect sense to me." -- That's half the battle right there, as I'm finding out. Even in the course of this thread, I've come up with a couple of situations where I might want to re-think a couple of my controllers (I plan to take my 8 view controller and break it out 3 & 5, and add a few more views -forgot about a news archive) Right now I'm using place holders in my views that I'll later replace with actual data as I build my models.

-tg

I was told about CakePHP being very similar to Rails, which is one reason why it may have gained much popularity. I've never personally used any of the PHP frameworks, but have heard good things about Cake.

I spent the better half of the summer developing a PHP-based framework using the MVC pattern (which is working very nicely, but not at a point where I would release it for public use). I was doing this mostly as an experiment, but also for practical reasons. I spent a lot of time looking at the way other PHP frameworks worked (Zend and Cake, for example), and also how other languages' popular frameworks worked: Python's Django, ColdFusion's Wheels. This provided great insight to how the MVC pattern worked.

The absolute basics -- models hold data; views deal with how things are displayed; controllers contain logic. If I were going to implement this "Widget" controller you described (into a made-up, non-existant MVC implementation), then the controller itself would be called WidgetController. I would have the following methods for this controller: view, add, edit, and remove. Each method would instantiate a different view. In the edit method, a list (your $cList) would be created, and then passed along to the view that could then be used. The view would then only be responsible for displaying the list:

PHP Code:

---

<ul>
<?php foreach($this->cList as $c): ?>
  <li><?php echo $c->getName(); ?></li>
<?php endforeach; ?>
</ul>

---

The controller would be responsible for creating $cList, then passing it along to the view to be used. In languages like Python, the Django framework must implement its own templating language in order to do what PHP does natively: embed code within HTML. When I set out to develop my framework, I wanted to mimic this and create my own templating language. Then, I realized that PHP already has this type of thing built-in. Of course, there is the downside of the fact that it is still possible to embed an entire script inside of a view, it just isn't a good idea. The developer should be aware of this, though, and not just have this rule forced upon them (I think).

The real advantage with the MVC pattern is good structure and organization. Separating your content from your logic (and then again from your data) is an important thing to do. Maintenance is easier. If the way things look ever needs to change, all you need to do is update all of your views -- your controllers (the logic) need not be touched.

I'm not sure if this was helpful.