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.