The response contains some methods to send out headers, add cookies, etc. It's not really that important.
Out of curiosity, I notice you have two arguments in your processRequest function. The request var is pretty self -explanatory, but what type of information is usually passed in the $response argument?
Well, that's the thing with abstraction: if there are some requests that do need a HTTPRequest object and others that don't, you have to choose for the ones that do need it. The HTTPRequest is almost always needed anyway, because it provides access to GET, POST and SERVER, etc. But if you think this is just overhead for your application, you can of course just use GET, POST and SERVER directly, nothing wrong with that.
What if HTTPRequest and\or HTTPResponse are not needed for a specific request (can't think of an example right now...): I have then created an HTTPRequest (and\or HTTPResponse) Object that is not going to be used.
Then you would essentially be making them global variables and possibly breaking layering by allowing any layer to access them, including layers that should remain independent of the request. By not making the objects singletons you force yourself to layer your application.
I am thinking to change the HTTPRequest and HTTPResponse to Singletons and not passing them around.
The authentication page controller is responsible for a page that displays a form asking for a username and password. That form needs to be validated and depending on whether the username & password are valid, a view needs to be chosen. You soon find yourself with code that looks a lot like the page controller for adding a user. I therefore think it makes sense to make this code a page controller as well.
In this event, I am thinking about just redirecting to required page as is ? Is that not simpler ?
I agree with you. The example code I provided is not a strict implementation of the pattern, it is a variation of it. However, Mojavi is not a true implementation of the FrontController pattern either, yet it claims to be (I'd be happy to explain the reasons for saying this)
I applaud your effort here to make things clear and simple, but I still think that you are blurring the definition of the page controller pattern by mixing the page controller and the front controller patterns together. Someone coming here wanting to understand the page controller pattern might be confused by how you are using the pattern. I propose that you name your new pattern something different than page controller to distinguish it from a true page controller pattern (as Fowler and others intended).
If you take a look at how Fowler defines the PageController here, there is nothing saying that there cannot be any other code responsible for choosing a PageController based on what the URL is, or that things like InterceptingFilters are not allowed.
Because of that, and also the fact that I think that the name PageController is the most descriptive of the task of the classes I provided, I don't really see a reason to change the name. I'd also like to mention that in my framework, FrontController is named EntryPoint, but what's in a name eh.. :)
That was the intention of my post: to provide an example of how all the patterns that are discussed about so much can be implemented together (note: can, not must).
I personally loved your MVC implementation. Very very simple and to the point. Put a lot of things into perspective, and DID clear up some minor confusions that I had about the "pattern."
Well, the User*PageControllers do not extend from a base UserController. Also, the formHasBeenSubmitted and formIsValid variables are not defined in that UserController. In the example I provided them simply to illustrate how the control flow looks like. The actual implementation of how forms are validated is left to the developer's creativity, since it is not directly part of the MVC pattern.