Is userObject from your Model Layer? I would prefer to send this info in a dataset... or at least using a hash. Would'nt you?
Yep, $userObject comes from my model layer. When you say you'd like to send it as a hash, do you mean an array like array('username' => ..., 'password' => ..., etc) or an array like array('user' => $userObject)? If you mean the first, then, well, I guess it's a matter of personal preference. You could pass the View an array instead of an object, the important thing is that it's some model data.
Switch/cases can quickly get very large. Dynamically invoking PCs can be a good option.
Completely agree. The switch statement was merely an example. For the app I'm developing now I use something like what you describe. But then again, the example was simply to illustrate what a FrontController should do. The actual implementaion of how that is done is up to the developer's creativity (or the framework writer :)).
It's the constant niggling questions like that that deter me from ever going near MVC. Any kind of coding structure that causes this much confusion over so many minor details must be going wrong somewhere.
That's because MVC does not say anything about this question: it leaves it up to you, the developer, to decide this to your best ability. MVC doesn't care about that, because that is not what the pattern is for.
My only question is about the base PageController and what should be in it? An example skeleton or psuedo-code of what should/could be in a base PageController is something that I have, as yet, been unable to find. Any directions would be greatly apprciated.
Here's something that would fit in with the example code:
Anything common to all the PCs - starting a session & authentication for example.
How common are those things to all Page Controllers? For the public section of a website, you don't need to authenticate users, right? I personally prefer to implement sessions & authentication through the use of InterceptingFilters. The FrontController can set these up. But you can achieve the same thing by having multiple PageController base classes: one for pages that do need authentication, one for those that don't need authentication, one for those that need authentication and sessions, one for those that only need sessions... see why a chain of intercepting filters might be more flexible?
Why do you invoke Page Controllers from your Front Controller? Doesn't that defeat the purpose of having a Page Controller in the first place? If Page Controllers are used, the Web server should act as the Front Controller. Instead, I would have a set of Command (or Action) classes (e.g. ViewNewsCommand, AddNewsCommand, UpdateNewsCommand, DeleteNewsCommand, etc.) and leave the Page Controllers out all together unless you are trying to reuse the Page Controller functionality somewhere else. These two patterns can certainly live together, but I have never seen one invoke the other or vice-versa.
You are essentially right. My FrontController is not one in the strict sense of how Martin Fowler describes it. What Fowler proposes is that a FrontController invokes commands on the model of the application and contains the logic for choosing a view. Fowler's FrontController is essentially a mix of the potentially large switch statements of my FrontController plus the logic for choosing a view that you find inside each PageController.
A ViewNewsCommand is not the type of command that the FrontController would invoke, that is not a domain model command. Domain model commands are independent of the presentation layer on top of it. They are things like CalculateInterestRatesCommand and MakeSSLPaymentCommand.
The code that you probably have in 'ViewNewsCommand' is probably something like this: create a DAO, find a News object by id and create a View object to display that news. When you follow Fowler's FrontController pattern, this code would be implemented inside the FrontController itself with the help of something like a GetNewsCommand. Now this may not seem like a big difference, but trust me, it is. GetNewsCommand is independent of the kind of presentation layer involved (it only loads a News object from the DB, no view choosing whatsoever), while ViewNewsCommand is not: it knows what View object it must create to display the news.
The Page Controller version, although extremely similar, uses the Web server as the Front Controller and would have a URL like this:
Alright, you could use the web server as the front controller (which isn't a true front controller either, by the Martin Fowler pattern). But you loose all the advantages that a FrontController in combination with PageControllers can give you:
- the ability to (dynamically) run Object Oriented!InterceptingFilters before passing on the request to a PageController instead of messing with auto_prepend_files and auto_append_files
- you can change the URL naming scheme of your website from something like index.php?page=whatever to /site/whatever by making a change in the FrontController instead of messing around with mod_rewrite for all page controllers
- have a central entry point for all the requests to your application. This is important to make the code readable and understanable, a clear structure of the 'flow of a request': from the FrontController possibly through the InterceptingFilters to a PageController. This instead of having to wade through if/else statements in auto_prepended files and to be unsure if control needs to be passed back to the actual requested page, redirected somewhere else, etc.
Notice how a combination of a FrontController and PageControllers is the Object Oriented equivalent of the procedural and messy combination of a web server, auto_prepend and auto_append files and possibly mod_rewrite? Since we are talking about a Design Pattern here, Object Oriented, I'd say that it makes sense