Trex is a lightweight and ease-to-use PHP 5 web application framework that allows users to speed up the development of web applications providing popular open source components. Its modular architecture enables users to incorporate their own modules and components to the system. Since Trex is compatible with the Zend Framework, any of its components may be loaded for independent use as needed.

One of the Trex framework’s most useful features is its implementation of the Front Controller and Model-View-Controller patterns.

1.1. System Architecture

The system architecture is based on the following programming paradigms:

• Object-oriented programming
• Modular programming

Architectural patterns

Trex is based on the Front Controller and Model-View-Controller architectural patterns.

Model-View-Controller pattern

• The Model represents your data structures. You might have a model class that contains functions to insert, update, and retrieve data.
• The View is the information that is being presented to a user. A View will normally be a web page.
• The Controller serves as an intermediary between the Model, the View and any other resources needed to process the HTTP request and generate a web page.

Front Controller pattern

The Controller is the heart of Trex framework’s MVC system. It implements a Front Controller pattern, in which all requests are intercepted by the Controller and dispatched to individual Action Controllers based on the URL requested. The Dispatcher is responsible for view management and navigation, managing the choice of the next view to present to the user.

1.2. Modular Architecture

In a typical website, a design is implemented so that it meets a set of requirements at the time of development. Often, after a website is delivered, the user will want added functionality, or different users will require custom functionality based on their specific needs. In order to accommodate these situations without a complete re-write, a framework that allows for future additions of modules without breaking the existing code base needs to be implemented. A modular architecture will meet these needs.

In Trex, modules are rather loosely coupled, you can replace or add any module without affecting the rest of the system.

“…it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.” - David Parnas

1.3. Directory Structure

Trex provides a standard file tree structure to organize all these contents in a logical way. This is the directory structure that is automatically created when initializing every project or module.

These are the directories found at the root of a project:

config/
global/
    views/
lib/
    Trex/
    Zend/
modules/
    module_name/
        config/
        models/
        public/
        setup/
        views/
        Controller.php
        ControllerAdmin.php
var/
    cache/
    log/

Directory Description

1.4. Routing

The Router class is the standard framework router. Routing is the process of taking a URI endpoint (that part of the URI which comes after the base URL) and decomposing it into parameters to determine which module, controller, and action of that controller should receive the request. The values of the module, controller, action and other parameters are packaged into a Controller_Router_Request_Http object which is then processed by Controller_Dispatcher. Routing occurs only once: when the request is initially received and before the first controller is dispatched.

1.5. Class Autoloading

In Trex, if you store all your classes in the lib/ directory, you don’t need to include them. That’s why the Trex projects usually do not contain any include or require statements.

1.6. Debugging

One of the goals of Trex is to provide an extensible component for logging. When code breaks, there are two ways to figure out what went wrong: launch a debugger, or add logging statements to see what’s going on. In its crudest form, logging means adding a few logError() calls here and there. An important use of logging is to provide an audit trail: who did what and when. The predominant pattern in Trex is to write such auditing information to the filesystem rather than the database. The logging component in Trex is intended to be used primarily for troubleshooting and debugging.

The debugger is enabled by default. You can always turn it off by setting the “debug” option to false in the config/DebugConfig.php file. Only authorized IP addresses can view the on-screen debugging messages and access the debug log.