PHP Objects, Patterns and Practice (3rd edition)

This simplified XML fragment shows one strategy for abstracting the flow of commands and their
relationship to views from the Command classes themselves. The directives are all contained within a
control element. The logic here is search based. The outermost elements defined are the most generic.
They can be overridden by their equivalents within command elements.
So the first element, view, defines the default view for all commands if no other directive contradicts
this order. The other view elements on the same level declare status attributes (which correspond to
flags set in the Command class). Each status represents a flag that might be set by a Command object to signal
its progress with a task. Because these elements are more specific than the first view element, they have
priority. If a command sets the CMD_OK flag, then the corresponding view “menu” is the one that will be
included, unless an even more specific element overrides this.
Having set these defaults, the document presents the command elements. By default, these elements
map directly to Command classes (and their class files on the file system) as in the previous
CommandResolver example. So if the cmd parameter is set to AddVenue, then the corresponding element in
the configuration document is selected. The string "AddVenue" is used to construct a path to the
AddVenue.php class file.
Aliases are supported, however. So if cmd is set to QuickAddVenue, then the following element is used:

Here, the command element named QuickAddVenue does not map to a class file. That mapping is
defined by the classroot element. This makes it possible to reference the AddVenue class in the context of
many different flows, and many different views.
Command elements work from outer elements to inner elements, with the inner, more specific,
elements having priority. By setting a view element within a command, I ensure that the command is tied to
that view.