All requests to an Eocene-based system are routed to one or more receivers (php pages that contain “freestanding” codes to activate the framework). Though most applications will use only one receiver, a complex application that receives a large number of different commands can use more than one receiver to divide the application into smaller sub-applications. Each receiver is associated with an xml-based configuration file (config file). For each command (e.g. clicking a link or submitting a form), the config file provides a command class and associated html pages (or templates). A receiver file can have any name (with a .php extension), thereby, providing the flexibility to use more than one receiver with different names and all residing in the same folder.
The receiver creates a front controller (FrontController) object by passing
the full path of its config file. The front controller is the only global variable
that is available in any php page in the system. After instantiating the front
controller, the receiver calls the execute() method of FrontController and then
it obtains the response for the request by calling the content property of the
response object. The response is echoed to the browser.
Internally, the front controller instantiates a command class and dispatches
the request to the command object for processing. You should write the command
class, deriving it from the BaseCommand class or a class that has BaseCommand
in its superclass hierarchy. You should also overwrite the execute method in
the command class and provide application specific logic. The BaseCommand class
provides template processing capabilities, shielding developers from manipulating
templates using codes. You only need to call methods in BaseCommand to process
your templates. You have, however, access to the TemplateEngine object in BaseCommand
if your requirements are not met by available methods in the BaseCommand
class.
Templates are html pages with tokens for generating dynamic contents. Tokens
are available for variable substitutions, if-then blocks, for-each loops, includes,
and plugs. Template tokens are very simple and no attempt is made to develop
“yet another” templating language. Variable substitutions can be made for simple
variables or array variables. Block tokens evaluate an if-then condition. There
is no if-then-else token. All if-then-else constructs should be broken into
simple block tokens. Loop tokens are used to simulate for-each loops. Include
tokens are used to include other templates that may, in turn, contain all the
template tokens described earlier.
Plug tokens are used for modular development or for generating complex dynamic
pages that cannot be generated using other tokens. A plug token in a template
is specified using a command attribute. Each command is associated with
a command class derived, directly or indirectly, from the BaseCommand class.
The command class for a plug returns some contents (strings) that are substituted in the template at the plug token location. Because a command class for a plug has BaseCommand in its superclass hierarchy, it can use other templates which, in turn, can use more plugs, includes, and other tokens. The possibilities are endless. Plugs provide flexibility to extend a template by codes that are separate from the template and keep template tokens simple, flexible, and powerful.
Comments