I’m experienced in working with MVC web applications (Zend Framework). When I was looking for a better description of each layer of the MVC pattern (i.e. Model, View, Controller) I’ve found the Page Controller pattern that describes a similar behavior as you can see on the image below:
http://martinfowler.com/eaaCatalog/pageController.html

The MVC pattern:
http://martinfowler.com/eaaCatalog/modelViewController.html

So far, the differences I’m able to identify, is that the controller on the MVC pattern found on various applications actually implement business logic by deciding the actions upon the model’s entities. Sometimes those actions will be performed within the Repository Pattern instead of accessing the model’s entities directly. Thus you will find applications that have a service layer as a facade for the business logic, in such cases, controllers are thin and do not have any business logic, just presentation logic whereby the view is determined accordingly with the http request data and the data returned by the Service (or Repository).
The main question is. Does MVC implement the Page Controller pattern as it is? Or the Controller on MVC is similar but have a distinct pattern?
Calling a controller that does implements business logic a PageController doesn’t sounds right, since it’s not just a “page controller”. But if we remove the business logic from the controller it does makes sense to call it a “page controller”.
Some background on the subject.
To begin with, you have to understand that it is impossible to write classical MVC in PHP. In the classical pattern the View is observing Model layer for any changes and requests new data when such change is detected. Which is impossible, when the View ends up in someones phone on the other side of planet or on ISS for that matter.
The closest you can get to classical structure is the Model2 MVC ( some call it "Web MVC" ). In this pattern the View is interacting with Model layer through services. These services in turn are encompassing the realization of domain model (as defined in this book) and the persistence abstractions. And the View requests all the data it needs from said services.
Other popular variations on original MVC theme are MVVM and MVP (there is also HMVC pattern, which has no direct relation to others and is a variation on PAC). As you might notice, the M and V stay in all , but the "controlling structure" has different names. That is because they each do different things.
Bact to original question ..
The short answer would be : NO.
You have to keep in mind that PoEAA was released some time around year 2002. Things changed a bit. Now the HTTP request gets usually handles by Front Controller, which then supplies parameters for creating the
Controller.It is still common for
Controllerto instantiate the structures fromModel layer, but theViewcan be instantiated either inside controller, or based onResponseobject which might be returned (or just altered) byController.Also, while in general there is still 1:1 relation between
ViewandController, there will be situations when that sameControlleris called to help generate JSON, instead of HTML. This would cause the controller to choose a different View, because in case of JSON-orientedView, it would be trying to accumulate some specific data fromModel layerand create a one of several possible data structures. Which then it encodes and presents the the user (which in this case, most likely, would be XRH object in browser).And these deviations only cover the Model2, and partly MVP.
Update v2:
In a web application controller’s main job is to pass data from request (preferably abstracted) to the model layer and thus – altering the model’s state. Controller can also alter the state of the current view instance. It usually happens when you want to change the output format.
The creation of view and model layer structures can (and usually – should) be located outside the Controller itself.
Also, please note that this is not what MVP and MVVM patterns do, which tend to gather the data from Model layer in the "controller", manipulate/restructure that data and only then pass it to View.