What is the actual pattern for MVC WRT WebApplications?

Question

The confusion is because of the different MVC architechture diagrams floating on the internet: Since the question would be too broad I want to concentrate on the MVC's used for WebApplications.

Say: Zend Framework.

example1: Probably the best one I have seen.

example 2:

example 3:
                                    
Model-view-controller concept. The solid line represents a direct association, the dashed an indirect association (via an observer for example).

What I am mainly concentrating is on, how the view interacts with controller(s) & model(s) vice versa.

• Should the view interact directly with model(s)?
• Should the model directly update any changes to the view(s)?
• Is the diagram in example2 a misinterpretation of MVC as it looks like its a MVP⁽¹⁾⁽²⁾pattern.

An example of MVC vs MVP:

Answer 1

Since no answer was posted, I decided to post one. This is largely based on
Model-View-Controller (MVC) Architecture (WEB) (PDF) . Pointed to by: Tom Ingram (Thanks).

The article is by:
John Deacon is a lecturer and writer. Object-Oriented Analysis and Design: A Pragmatic Approach. (for more on the author refer the section About the author here )

Now, the diagram best suited for the MVC architecture is:
                  

The three parts:

Model-View-Controller:

We will call the unchanging essence of the application/domain, the model (in the singular). In object-oriented terms, this will consist of the set of classes which model and support the underlying problem, and which therefore will tend to be stable and as long-lived as the problem itself.
How much should the model (classes) know about the connection to the outside world? Nothing, absolutely nothing.

Model-View-Controller:

For a given situation, in a given version there will be one or more interfaces with the model, which we'll call the views (plural). In object-oriented terms, these will consist of sets of classes which give us "windows" (very often actual windows) onto the model, e.g.

• The GUI/widget (graphical user interface) view,
• The CLI (command line interface) view,
• The API (application program interface) view.

Or:

• The novice view,
• The expert view.

Although views are very often graphical, they don't have to be.

What will the views know about the model? They have to know of its existence. They have to know something of its nature. A bookingDate entry field, for example, might display, and perhaps change, an instance variable of some model class somewhere.

Model-View-Controller:

A controller is an object that lets you manipulate a view. Over-simplifying a bit, the controller handles the input whilst the view handles the output. Controllers have the most knowledge of platforms and operating systems. Views are fairly independent of whether their event come from Microsoft Windows, X Windows or whatever.

And, just as the views know their model but the model doesn't know its views, the controllers knows their views but the view doesn't know its controller.*

Controllers were Smalltalk specific. They are not of general interest and are not covered in any greater depth here. In Java's Swing architecture, for example, the view and the controller are combined (this is often done in other architectures). In Swing the combined view/controller is called the delegate.

*Read carefully and digest.

---

There is also about (go through them):

"Model" confusion

Smalltalk, then, can be credited with inventing and promoting the MVC architecture. But it could also be accused of confusing things. A better acronym for the architecture would be: M_dM_aVC.
M_d: The domain model.
M_a: The application model.

& about how the communication should occur:

• View to model communication.
• Model (and controller) to view communication.
• Application model to domain model communication.

I think this should give us a very clear picture of What is the actual pattern for MVC?.