Request response lifecycle

When working with any tool, it is important to understand how the tool works. Here we can look under the bonnet at what makes WebEngine work so you can use the knowledge to make the best decisions in writing applications.

Within PHP.Gt, everything is broken down into its own repository of single responsibility. The PHP.Gt WebEngine brings all of these components together to produce a full application framework. As the name suggests, this framework utilises web technologies and the purpose of this page of the documentation is to walk through what goes into the whole lifecycle of the application.

Step 0: Web server

Before any code is executed, a web request will be handled by the web server. This can be any server, such as NGINX, Apache or the inbuilt server.

The job of the server is to listen for HTTP requests from web browsers across the internet and send back the correct response. A valid response can be a static file, such as an image, a WebEngine page handled by your code, or a 404 Not Found message.

For a web server to handle WebEngine pages, the request/response lifecycle begins. The entry point of all WebEngien requests is the go.php file in the root of the WebEngine directory. If WebEngine is installed using Composer, the path will be vendor/phpgt/webengine/go.php.

See the web servers section for more information about configuring servers and using the inbuilt server.

Step 1: Go!

The go.php file firstly checks to see if the incoming requested file exists in the public web root of your application. If a static file exists, the script simply returns false. This is used by the inbuilt server as to not accidentally process static files. "Real" web servers such as NGINX and Apache should not get this far, as they should serve static files themselves.

Next, the Composer autoloader is loaded. This allows object oriented code to be loaded automatically and efficiently based on the namespaces of the classes used. Read the introduction to Composer article at getcomposer.org for more information.

Finally, now the Composer autoloader is in place, we can utilise the benefits of object oriented code by instantiating our first object - the Lifecycle object. We call the start() function of the Lifecycle object to jump into object oriented code. From here on, all executed code is done in a structured, predictable and understandable manner, thanks to Composer's autoloading namespaces.

Step 2: The start of the Lifecycle

The Lifecycle class initialises and calls the core elements of PHP.Gt that make up the WebEngine. The start function abstracts this as much as possible, giving you a high-level overview of what's going on.

Within the start function, all core objects are created:

• ServerInfo - an object oriented representation of $_SERVER superglobal.
• Config - loads configuration variables from .ini files and environment variables.
• Input - the object for accessing user input (GET / POST parameters).
• CookieHandler - an object oriented representation of $_COOKIE superglobal.
• SessionHandler - an object oriented representation of $_SESSION superglobal.
• Database - the object for accessing the database.
• Request - a [PSR-7 compliant] representation of the incoming HTTP request.
• Router - an object that matches the incoming request to the correct area of your code.
• Dispatcher - an object that creates and calls your code in the correct order.
• Response - a PSR-7 compliant representation of the outgoing HTTP response.

With the above objects created, the Lifecycle object passes them to areas of WebEngine and your code where required. Let's continue the journey...

Step 3: Configuration

The responsibility of loading project configuration is maintained within the PHP.Gt/Config repository. In WebEngine, we call the ConfigFactory's createForProject function which allows many .ini files to be loaded, overriding defaults where necessary. This is useful to allow for different configuration per environment, such as on a staging server versus the live server.

Learn more about configuration in the Configuration page.

Step 4: Session handler

PHP's sessions that are typically loaded into the $_SESSION superglobal are done so through a class that implements SessionHandlerInterface. PHP.Gt/Session provides an alternative session handler that

Step 5: Protection of global variables

As the Lifecycle class is at the very beginning of the request/response lifecycle, it has a very important job of protecting the use of global variables.

Step 6: Attach autoloaders

// TODO.

Step 7: Request

// TODO.

Step 8: Router

// TODO.

Step 9: Dispatcher

// TODO.

Step 10: Process

Lifecycle implements MiddlewareInterface, a well-known definition for HTTP Server Request Handlers (PSR-15). This interface comes with the the process method whose job is simply to take a PSR-7 Request object and return a PSR-7 Response object.

Step 11: Finish

The last step is the simplest. After all of the above has been completed, the finish function's only job is to echo the body of the response to the browser.