Download the PHP package lucinda/mvc without Composer

Example:

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:

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 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 (Runnable interface.

Installation

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

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

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

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:

• 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:

• 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):

To understand more how parameters work, check tag documentation!

Abstract Class EventListeners Start

Abstract class EventListeners\Start implements Runnable) and listens to events that execute BEFORE configuration XML is read.

Developers need to implement a run method, where they are able to access following protected fields injected by API via constructor:

A common example of a START listener is the need to set start time, in order to benchmark duration of handling later on:

Abstract Class EventListeners Application

Abstract class EventListeners\Application implements Runnable) and listens to events that execute AFTER configuration XML is read.

Developers need to implement a run method, where they are able to access following protected fields injected by API via constructor:

Usage example:

https://github.com/aherne/lucinda-framework/blob/master/src/EventListeners/SQLDataSource.php

Abstract Class EventListeners Request

Abstract class EventListeners\Request implements Runnable) and listens to events that execute AFTER Cookies objects are created.

Developers need to implement a run method, where they are able to access following protected fields injected by API via constructor:

Usage example:

https://github.com/aherne/lucinda-framework/blob/master/src/EventListeners/Security.php

Abstract Class EventListeners Response

Abstract class EventListeners\Response implements Runnable) and listens to events that execute AFTER Lucinda\MVC\Response body was set but before it's committed back to caller.

Developers need to implement a run method, where they are able to access following protected fields injected by API via constructor:

Usage example:

https://github.com/aherne/lucinda-framework/blob/master/src/EventListeners/HttpCaching.php

Abstract Class EventListeners End

Abstract class EventListeners\End implements Runnable) and listens to events that execute AFTER Lucinda\MVC\Response was rendered back to caller.

Developers need to implement a run method, where they are able to access following protected fields injected by API via constructor:

A common example of a START listener is the need to set end time, in order to benchmark duration of handling:

Abstract Class Controller

Abstract class Controller implements Runnable) to set up response (views in particular) by binding information detected beforehand to models. It defines following public method relevant to developers:

Developers need to implement run method for each controller, where they are able to access following protected fields injected by API via constructor:

Usage example:

https://github.com/aherne/lucinda-framework-configurer/blob/master/files/controllers/no_rest/IndexController.php

To understand more about how controllers are detected, check specifications!

Class Attributes

Class Attributes encapsulates data collected throughout request-response cycle, each corresponding to a getter and a setter, and made available to subsequent event listeners or controllers. API already comes with following:

Most of the data collected will need to be set by developers themselves to fit their project demands so in 99% of cases class will need to be extended for each project! Usage example:

https://github.com/aherne/lucinda-framework/blob/master/src/Attributes.php

Specifications

Since this API works on top of Abstract MVC API specifications it follows their requirements and adds extra ones as well:

• How Is Response Format Detected
• How Are View Resolvers Located
• How Is Route Detected
• How Are Controllers Located
• How Are Parameter Validators Working
• How to Set Cookies Path and Domain
• How Are Uploaded Files Processed
• How Is Requested URI Processed
• How Are Views Located

How Is Response Format Detected

This section follows parent API specifications only that routes are detected based on value of $_SERVER["REQUEST_URI"].

How Are View Resolvers Located

This section follows parent API specifications in its entirety.

How Is Route Detected

This section follows parent API specifications only that routes are detected based on value of $_SERVER["REQUEST_URI"]. Let's take this XML for example:

There will be following situations for above:

How Are Controllers Located

This section follows parent API specifications only that class defined as controller attribute in Controller.

How Are Parameter Validators Working

To better understand how validators attribute in routes tag in order to locate validators to run based on incoming request, let's take this XML for example:

When a request to /users/aherne is received, API will:

• detect route with id users/(uname) and request parameters received (path parameters, GET, POST)
• check if route is called with GET method. If not, a MethodNotAllowedException is thrown!
• instances Lucinda\Project\ParameterValidators\UserName and runs validate method on value of "uname" path parameter. If param not sent or validation fails, a ValidationFailedException is thrown!

When a request to /users/info is received, API will:

• detect route with id user/info and request parameters received (path parameters, GET, POST)
• check if route is called with POST method. If not, a MethodNotAllowedException is thrown!
• instances Lucinda\Project\ParameterValidators\UserId and runs validate on value of "id" request parameter. If param not sent or validation fails, a ValidationFailedException will be thrown!
• instances Lucinda\Project\ParameterValidators\UserName and runs validate on value of "name" request parameter. If param sent and validation fails, a ValidationFailedException will be thrown!

All parameter validators need to be PSR-4 autoload compliant and implement EventListeners\Validators\ParameterValidator!

How to Set Cookies Path and Domain

Table below shows the effects of path attribute @ cookies XML tag:

Table below shows the effects of domain attribute @ cookies XML tag:

How Are Uploaded Files Processed

Unlike $_FILES superglobal, like parameters sent by $_GET or $_POST, API preserves structure sent in form, so:

Once posted, uploadedFiles method will return:

Where object is a Request!

How Is Requested URI Processed

API breaks down requested URI (value of REQUEST_URI param @ $_SERVER) into relevant components based on following algorithm:

• it first detects context path by stripping SCRIPT_FILENAME from DOCUMENT_ROOT. Normally, context path is empty since sites are deployed to a specific hostname, but there are cases in which they are deployed on localhost directly, so when REQUEST_URI is http://localhost/mySite/foo/bar, context path will be mySite
• it strips context path and QUERY_STRING from REQUEST_URI in order to detect requested page. If no specific page was requested as in http://www.example.com, homepage is assumed, so requested page will be an empty string
• it records query string and its array representation based on QUERY_STRING param @ $_SERVER. Recording an array representation of query string parameters separate from that returned by parameters method of Request is justified when a non-GET request is received.

Examples:

How Are Views Located

This section follows parent API specifications in its entirety. Extension is yet to be decided, since it depends on type of view resolved!