CHAPTER 12 ■ ENTERPRISE PATTERNSFigure 12–9. A Page Controller class hierarchy and its include relationships
Consequences
This approach has the great merit that it immediately makes sense to anyone with any Web experience. I
make a request for venues.php, and that is precisely what I get. Even an error is within the bounds of
expectation, with “server error” and “page not found” pages an everyday reality.
Things get a little more complicated if you separate the view from the page controller class, but the
near one-to-one relationship between the participants is clear enough.
One potential area of confusion lies with the inclusion of views. A page controller includes its view
once it has completed processing. In some circumstances, though, it might use the same inclusion code
to include another page controller. So, for example, when AddVenue successfully adds a venue, it no
longer needs to display the addition form. Instead it delegates to another page controller called
ListVenues. You need to be clear about when you are delegating to a view and when you are delegating
to another page controller. It is the responsibility of the page controller to ensure that its views have the
data they need to do their jobs.
Although a page controller class might delegate to Command objects, the benefit of doing so is not as
marked as it is with Front Controller. Front controller classes need to work out what the purpose of a
request is; page controller classes already know this. The light request checking and logic layer calls that
you would put in a Command sit just as easily in a page controller class, and you benefit from the fact that
you do not need a mechanism to select your Command objects.
Duplication can be a problem, but the use of a common superclass can factor away a lot of that. You
can also save on setup time, because you can avoid loading data you won’t be needing in the current
context. Of course, you could do that with Front Controller too, but the process of discovering what is
needed, and what is not, would be much more complicated.
The real drawback to the pattern lies in situations where the paths through your views are
complex—especially when the same view is used in different ways at different times (add and edit
screens are a good example of this). You can find that you get tangled up in conditionals and state
checking, and it becomes hard to get an overview of your system.
It is not impossible to start with Page Controller and move toward the Front Controller pattern,
however. This is especially true if you are using a PageController superclass.