First, an obligatory explanation:
[INDENT]The original definition of MVC was written with desktop applications in mind, and it doesn't translate perfectly to stateless, server-side web applications. For example, MVC controllers are supposed to handle user input -- such as mouse clicks, key presses, touches, gestures, device orientation, etc -- and translate that input into commands for the view and the model. But in server-side web applications, there's only one input: the HTTP request. Also, MVC views are supposed to be able to react to user input as well as to changes in the model, but in server-side web applications, there won't be any new user input for the view to react to, nor will there be any changes in the model that would require the view to update itself.
Because of these differences, MVC has typically been implemented differently for the web. Views became templates, and the templates don't access the model directly. Instead they are fed data by the controller, which acts as a mediator between the model and the view. It turns out there's another design pattern that more accurately reflects the way server-side web applications typically work, called Presentation–abstraction–control.[/INDENT]
With that explanation out of the way, I think we need to know which "kind" of MVC you're trying to implement before we can help. If you'd like to implement MVC in its original, purest sense, then @TomB ; can help you with that. Or if you'd like to implement the kind of MVC that today's popular frameworks are built on, then I and some others here can help you with that too.