If you haven't read Part one, go do it! It provides the background for these classes.
In Part 1, I explain my base classes: MVC_Controller, MVC_View and MVC_Model. For my simple links application I extend the model class and the controller class. I did not need to extend the view for my purposes.

As I said before, the "action" variable is actually the name of the method you want to run. I listed the actions previously that I will need (planning ahead, what a concept) so it makes it easy to implement now:

I call the parent method constructor. Then I create a new instance of the ListModel class. I set a directory for my templates for the view model (which was instantiated in the MVC_Controller class). Then I call doAction, which if this is the first time the page was accessed then there would be no "action" set. So, what happens when there is no action set? $this->defaultMethod() is called which I redefined here:

How simple is that? I love this. I can have all my sql in one file, so it makes it so much easier to just sit and write all the sql I will need at once. The templates are in html (with smarty) so I can edit them in a nice editor like Dreamweaver, and no more printing out html with php.

I use PearDB (but you can use anything, straight php mysql_* calls if you'd like) to get a result set, store in private variable then the fetchToArray method I defined in the parent class iterates over the result set and puts it into an array. Some might think this is "ok" to do in a view, but I'd rather keep as much logic out of the template as possible. Its bad enough that I have "if" statements in there!

This is just the ultimate simple template, you can always change it later to make it more pretty. Notice the form at the top, with the hidden variable "action" set to value "showAddForm" ? when you click that it will send "showAddForm" as the action to the controller and it will display the form to add a link.

Back to the controller, we see that method looks like this:

function showAddForm() {
$this->view->display('link_ae');
}

I called my template "link_ae" to stand for "link add/edit" a convention picked up from DotProject.

I could do some checking to make sure the query was a success, returned a confirmation message to the controller which could then send it to a view to display the message.

Yeah. So what.
You might think, this is just a tiny app and you don't need to do all this for just storing a list of links in the database. Oh this is small I can just hack it. Yes, you could. But I bet it would take longer. What if The Powers That Be see this and go OH HEY! make it do this and that! and then they want to change how its displayed and you had hammered out all that HTML in print statements.
Separating things out, like model and view is extremely helpful even for working in a team. You can assign one person to do the model and write all the sql statements. Someone else can write the templates. In addition, it makes it easier when you change template solutions (or decide "I don't need no stinkin' template" and just use PHP) or DB abstraction etc.

I hope this helped you learn more about MVC even if you aren't using a bona fied framework.

I did use a DAO, PearDB. But I think you are thinking of "ORM" object relation mapping (I think thats the right term?) to take the database result and turn it into an object which makes it easier to use. Rails has ActiveRecord. Pear has something called DB_DataObject, which I've used a little bit.