CHAPTER 12 ■ ENTERPRISE PATTERNS}
$this->invokeView( $app_c->getView( $request ) );
}
function invokeView( $target ) {
include( "woo/view/$target.php" );
exit;
}
As you can see, the principal difference from the previous Front Controller example is that here
Command objects are retrieved and executed in a loop. The code also uses AppController to get the name
of the view that it should include. Notice that this code uses a registry object to acquire the
AppController.
So how do I move from a cmd parameter to a chain of commands and ultimately a view?
Implementation Overview
A Command class might demand a different view according to different stages of operation. The default
view for the AddVenue command might be a data input form. If the user adds the wrong kind of data, the
form may be presented again, or an error page may be shown. If all goes well, and the venue is created in
the system, then I may wish to forward to another in a chain of Command objects: AddSpace, perhaps.
The Command objects tell the system of their current state by setting a status flag. Here are the flags
that this minimal implementation recognizes (set as a property in the Command superclass):
private static $STATUS_STRINGS = array (
'CMD_DEFAULT'=>0,
'CMD_OK' => 1,
'CMD_ERROR' => 2,
'CMD_INSUFFICIENT_DATA' => 3
);
The application controller finds and instantiates the correct Command class using the Request object.
Once it has been run, the Command will be associated with a status. This combination of Command and
status can be compared against a data structure to determine which command should be run next, or—
if no more commands should be run—which view to serve up.
The Configuration File
The system’s owner can determine the way that commands and views work together by setting a set of
configuration directives. Here is an extract: