PHP Objects, Patterns and Practice (3rd edition)

CHAPTER 12 ■ ENTERPRISE PATTERNS

<?php print $venue->getName(); ?>

<?php } ?>

This document has two elements to it. The view element handles display, while the controller
element manages the request and invokes application logic. Even though view and controller inhabit the
same page, they are rigidly separated.
There is very little to this example (aside from the database work going on behind the scenes, of
which you’ll find more in the section “The Data Layer”). The PHP block at the top of the page attempts to
get a list of Venue objects, which it stores in the $venues global variable.
If an error occurs, the page delegates to a page called error.php by using include(), followed by
exit() to kill any further processing on the current page. I prefer this mechanism to an HTTP forward,
which is much more expensive and loses any environment you may have set up in memory. If no include
takes place, then the HTML at the bottom of the page (the view) is shown.

Figure 12–8. Page Controllers embedded in views

This will do as a quick test, but a system of any size or complexity will probably need more support
than that.
The Page Controller code was previously implicitly separated from the view. Here, I make the break
starting with a rudimentary Page Controller base class:

namespace woo\controller;
//...

abstract class PageController {
private $request;
function __construct() {
$request = \woo\base\RequestRegistry::getRequest();
if ( is_null( $request ) ) { $request = new Request(); }
$this->request = $request;
}

abstract function process();

function forward( $resource ) {
include( $resource );
exit( 0 );