README

Table of contents:

About
Configuration
Binding Points
Execution
Installation
Unit Tests
Reference Guide
Specifications

About

This API is a skeleton (requires binding by developers) created to efficiently handle web requests into server responses using a MVC version where views and models are expected to be independent while controllers mediate between the two based on user request. Designed with modularity, efficiency and simplicity at its foundation, API is both object and event oriented: similar to JavaScript, it allows developers to bind logic that will be executed when predefined events are reached while handling.

API does nothing more than standard MVC logic, so in real life it expects a web framework to be built on top to add further features (eg: DB connectivity). In order to use it, following steps are required from developers:

configuration: setting up an XML file where this API is configured
binding points: binding user-defined components defined in XML/code to API prototypes in order to gain necessary abilities
initialization: instancing FrontController, a Runnable able to handle requests into responses later on based on above two
binding events: setting up Runnable classes that will be instanced and run when predefined events are reached during handling process
configuring shared variables: extend Attributes class to encapsulate variables specific to your project, to be shared between event listeners and controllers
handling: calling run method @ FrontController to finally handle requests into responses, triggering events above (if any)

API is fully PSR-4 compliant, only requiring Abstract MVC API for basic MVC logic, PHP8.1+ interpreter and SimpleXML extension. To quickly see how it works, check:

installation: describes how to install API on your computer, in light of steps above
reference guide: describes all API classes, methods and fields relevant to developers
unit tests: API has 100% Unit Test coverage, using UnitTest API instead of PHPUnit for greater flexibility
example: shows a deep example of API functionality based on FrontController unit test

All classes inside belong to Lucinda\STDOUT namespace!

Configuration

To configure this API you must have a XML with following tags inside:

application: (mandatory) configures your application on a general basis
resolvers: (mandatory) configures formats in which your application is able to resolve responses to
routes: (mandatory) configures routes that bind requested resources to controllers and views
session: (optional) configures options to use automatically when creating sessions
cookies: (optional) configures options to use automatically when setting cookies

Application

Tag documentation is completely covered by inherited Abstract MVC API specification! Since STDIN for this API is made of HTTP(s) requests, value of default_route attribute must point to index (homepage) for requests that come with no route.

Resolvers

Tag documentation is completely covered by inherited Abstract MVC API specification!

Routes

Maximal syntax of this tag is:

<routes>
    <route id="..." controller="..." view="..." format="..." method="...">
        <parameter name="..." validator="..." mandatory="..."/>
        ...
    </route>
    ...
</routes>

Most of tag logic is already covered by Abstract MVC API specification. Following extra observations need to be made:

id: (mandatory) requested requested resource url without trailing slash. Can be an exact url (eg: foo/bar) or a url pattern (eg: user/(id)). If pattern is used, each variable must be named and enclosed in parenthesis!
controller: (optional) name of user-defined PS-4 autoload compliant class (including namespace) that will mitigate requests and responses based on models.
Class must be a Controller instance!
method: (optional) holds single HTTP method by which resource MUST be requested with. If request comes with a different method, a MethodNotAllowedException is thrown!

Tag example:

<routes>
    <route id="index" controller="Lucinda\Project\Controllers\Homepage" view="index"/>
    <route id="user/(id)" controller="Lucinda\Project\Controllers\UserInfo" view="user-info">
</routes>

^ It is mandatory to define a route for that defined by default_route attribute @ application XML tag!

If request came without route, default route is used. If, however, request came with a route that matches no id, a PathNotFoundException is thrown!

Route Parameters

Each route tag can hold one or more rules to validate values of request and path parameters that came along with request. Each parameter corresponds to a parameter tag, where validation is configurable based on attributes:

name: (mandatory) name of request or path parameter you want to validate. Examples:
- foo, if request was GET and came with query-string ?foo=bar
- id, if route url is user/(id)
validator: (mandatory) name of user-defined PS-4 autoload compliant class (including namespace) that will validate value of parameter.
Must be a EventListeners\Validators\ParameterValidator instance!
mandatory: (optional) holds whether or not parameter is mandatory (value can be 0 or 1). If none, mandatory (1) is assumed!

^ If parameter names collide, path parameters take precedence over request parameters!

Tag example:

<routes>
    <route id="index" controller="Lucinda\Project\Controllers\Homepage" view="index"/>
    <route id="user/(id)" controller="Lucinda\Project\Controllers\UserInfo" view="user-info" method="GET">
        <parameter name="id" validator="Lucinda\Project\ParameterValidators\UserNameValidator"/>
    </route>
</routes>

Session

Maximal syntax of this tag is:

<session save_path="..." name="..." expired_time="..." expired_on_close="..." https_only="..." headers_only="..." referrer_check="..." handler="..." auto_start="...">

Where:

save_path: (optional) absolute path in which sessions are saved on server. Example: "/tmp/sessions/"
name: (optional) name of the session which is used as cookie name (default: PHPSESSID). Example: "SESSID"
expired_time: (optional) number of seconds after which data will be garbage collected. Example: "60"
expired_on_close: (optional) number of seconds session cookie is expected to survive in client browser after close. Example: "120"
https_only: (optional) marks session cookie as accessible over secure HTTPS connections. Value: "1"
headers_only: (optional) marks session cookie as accessible only through the HTTP protocol. Value: "1"
referrer_check: (optional) substring you want to check each HTTP Referer for in order to validate session cookie. Example: "Chrome"
handler: (optional) name of user-defined PS-4 autoload compliant class (including namespace) that implements \SessionHandlerInterface. Example: "application/models/RedisHandler"
auto_start: (optional) signals session to be started automatically for each request. Value: "1"

Tag example:

<session save_path="/tmp/sessions/" name="SESSID" expired_time="60" expired_on_close="120" https_only="1" headers_only="1" referrer_check="Chrome" handler="application/models/RedisHandler" auto_start="1">

Cookies

Maximal syntax of this tag is:

<cookies path="..." domain="..." https_only="..." headers_only="...">

Where:

path: (optional) path on the server in which the cookie will be available on. Example: "/foo/"
domain: (optional) the (sub)domain that the cookie is available to. Example: "www.example.com"
https_only: (optional) signals cookie should only be transmitted over a secure HTTPS connection from the client. Value: "1"
headers_only: (optional) signals cookie should be made accessible only through the HTTP protocol. Value: "1"

Tag example:

<cookies path="/" domain="example.com" https_only="1" headers_only="1">

To understand how to properly set path and domain when needed, check specification!

Binding Points

In order to remain flexible and achieve highest performance, API takes no more assumptions than those absolutely required! It offers developers instead an ability to bind to its prototypes in order to gain certain functionality.

Declarative Binding

It offers developers an ability to bind declaratively to its prototype classes/interfaces via XML:

Programmatic Binding

It offers developers an ability to bind programmatically to its prototypes via FrontController constructor:

and addEventListener method (see: Binding Events section)!

Execution

Initialization

Now that developers have finished setting up XML that configures the API, they are finally able to initialize it by instantiating FrontController.

Apart of method run required by Runnable interface it implements, class comes with following public methods:

Where:

$documentDescriptor: relative location of XML configuration file. Example: "configuration.xml"
$attributes: see configuring shared variables.
$type: event type (see binding events below) encapsulated by enum EventType
$className: listener class name, including namespace and subfolder, found in folder defined when Attributes was instanced.

Example:

$handler = new FrontController("configuration.xml", new MyCustomAttributes("application/event_listeners");
$handler->run();

Binding Events

As mentioned above, API allows developers to bind listeners to handle lifecycle events via addEventListener method. Each EventType corresponds to an abstract Runnable class:

Listeners must extend matching event class and implement required run method holding the logic that will execute when event is triggered. It is required for them to be registered BEFORE run method is ran:

$handler = new FrontController("stdout.xml", new FrameworkAttributes("application/listeners");
$handler->addEventListener(EventType::APPLICATION, Lucinda\Project\EventListeners\Logging::class);
$handler->addEventListener(EventType::REQUEST, Lucinda\Project\EventListeners\Security::class);
$handler->run();

To understand how event listeners are located, check specifications!

Configuring Shared Variables

API allows event listeners to set variables that are going to be made available to subsequent event listeners and controllers. For each variable there is a:

setter: to be ran once by a event listener
getter: to be ran by subsequent event listeners and controllers

API comes with Attributes, which holds the foundation every site must extend in order to set up its own variables. Unless your site is extremely simple, it will require developers to extend this class and add further variables, for whom setters and getters must be defined!

Handling

Once above steps are done, developers are finally able to handle requests into responses via run method of FrontController, which:

detects EventListeners\Start listeners and executes them in order they were registered
encapsulates configuration XML file into Application object
detects EventListeners\Application listeners and executes them in order they were registered
encapsulates request information based on $_SERVER superglobal into Request object
encapsulates session information based on $_SESSION superglobal as well as operations available into Session object
encapsulates cookie operations and variables based on $_COOKIE superglobal as well as operations available into Cookie object
detects EventListeners\Request listeners and executes them in order they were registered
initializes empty Lucinda\MVC\Response based on information detected above from request or XML
locates Controller based on information already detected and, if found, executes it in order to bind models to views
locates Lucinda\MVC\ViewResolver based on information already detected and executes it in order to feed response body based on view
detects EventListeners\Response listeners and executes them in order they were registered
sends Lucinda\MVC\Response back to caller, containing headers and body
detects EventListeners\End listeners and executes them in order they were registered

All components that are in developers' responsibility (Controller, Lucinda\MVC\ViewResolver, along with event listeners themselves, implement Runnable interface.

Installation

First choose a folder, then write this command there using console:

composer require lucinda/mvc

Rename folder above to DESTINATION_FOLDER then create an .htaccess file there with following content:

RewriteEngine on
Options -Indexes
ErrorDocument 404 default
RewriteCond %{REQUEST_URI} !^/public
RewriteRule ^(.*)$ index.php

Then create a configuration.xml file holding configuration settings (see configuration above) and a index.php file (see initialization above) in project root with following code:

$controller = new Lucinda\STDOUT\FrontController("configuration.xml", new Attributes("application/events"));
// TODO: add event listeners here
$controller->run();

Unit Tests

For tests and examples, check following files/folders in API sources:

test.php: runs unit tests in console
unit-tests.xml: sets up unit tests and mocks "loggers" tag
tests: unit tests for classes from src folder

Reference Guide

These classes are fully implemented by API:

Application: reads configuration XML file and encapsulates information inside
Request: encapsulates user request based on information in superglobals: $_SERVER, $_POST, $_GET
- Request\Client: encapsulates client information detected from request
- Request\Server: encapsulates server information detected from request
- Request\URI: encapsulates uri information detected from request
- Request\UploadedFiles\File: encapsulates information about an uploaded file
Session: encapsulates operations to perform with a http session mapped to $_SESSION superglobal
Cookies: encapsulates operations to perform with a http cookie mapped to $_COOKIE superglobal

Apart of classes mentioned in binding events, following abstract classes require to be extended by developers in order to gain an ability:

Controller: encapsulates binding Request to Lucinda\MVC\Response based on user request and XML info
EventListeners\Validators\ParameterValidator: performs validation of a request parameter value

Class Application

Class Application encapsulates information detected from XML and defines following public methods relevant to developers:

Class Request

Class Request encapsulates information detected about user request based on superglobals ($_SERVER, $_GET, $_POST, $_FILES) and defines following public methods relevant to developers:

Class Request Client

Class Request\Client encapsulates client information detected from request based on $_SERVER superglobal and defines following public methods relevant to developers:

Class Request Server

Class Request\Server encapsulates web server information detected from request based on $_SERVER superglobal and defines following public methods relevant to developers:

Class Request URI

Class Request\URI encapsulates path information detected from request based on $_SERVER superglobal and defines following public methods relevant to developers:

To understand how requested URI is processed by this class, check specifications!

Class Request UploadedFile

Class Request\UploadedFiles\File encapsulates information about a single file uploaded based on $_FILES superglobal and defines following public methods relevant to developers:

To process file uploaded, two methods were added for developers:

To understand how uploaded files are processed into this class, check specifications!

Class Session

Class Session encapsulates operations to perform with a http session via $_SESSION superglobal and defines following public methods, all relevant to developers:

Class Session Cookie

Class Session\Cookie encapsulates operations to perform with a http session cookie and defines following public methods, all relevant to developers:

Class Cookies

Class Cookies encapsulates operations to perform with a http cookie via $_COOKIE superglobal and defines following public methods, all relevant to developers:

Interface ParameterValidator

Interface EventListeners\Validators\ParameterValidator implements blueprint for a single request parameter value validation via method:

Example of a class that validates user name received as parameter (eg: /user/(name) route):

class UserNameValidator implements Lucinda\STDOUT\EventListeners\Validators\ParameterValidator
{
    public function validate($value)
    {
        $result = DB("SELECT id FROM users WHERE name=:name", [":name"=>$value])->toValue();
        return ($result?$result:null);
    }
}

To understand more how parameters work, check specifications and tag documentation!