PunyMVC

PunyMVC is a work-in-progress minimalistic ultra-light MVC framework for PHP applications.

It is designed to be simple and straight-to-the-point, but at the same time modular, well organized and easy to extend or change.

Although it is already usable, it's still in a very early stage so it may (and most probably will) have some bugs, and some features may not work correctly in all kinds of situations.

Directory Structure

This is a default directory structure for a PunyMVC application. "public" is the web server document root, can have any name and be anywhere, as long as all requests go through his index.php file. "PunyMVC" is the core directory. "application" is the default application root

• application/
  • controllers/
  • models/
  • libraries/
  • views/
• public/
  • index.php (all requests must go through here)
• PunyMVC/
  • Request.php
  • Response.php
  • PunyMVC.php
  • Router.php
  • Controller.php
  • Library.php
  • Model.php
  • Database.php
  • Loader.php
  • View.php
  • Config.php

Core Classes:

• Request The Request class represents a HTTP request, and has method to access request information like request headers, request method, POST or GET params, raw request body, etc.
• Response The Response class represents a HTTP response, and handles all the output like HTTP headers, Status Codes, raw output or MVC Views.
• PunyMVC This is the framework main class. To start a PunyMVC application you must create a PunyMVC instance. It has methods to set routes, configure database access, add configuration settings, etc. In the end, call the PunyMVC->run() method and let it handle your requests.
• Router The Router class takes a Request and tries to match one of the specified routes with the Request Uri to find an appropriate controller to process the request.
• Controller The Controller class is the heart of your application. The PunyMVC object, after locating a suitable controller for the request, will instance it and call the defined method, passing along the Request Object and a new, (almost) empty Response Object. All developer created controllers must extend this Controller class. This class extends the Loader class, so that developers can access Models, Libraries and Configuration items within their controllers.
• Library The Library class is a parent for developer created custom classes, or libraries. It extends the Loader class, so developers can access other Libraries, Models or Configuration items from whitin their own libraries. Developer libraries must extend this Library class.
• Model The Model class is a parent class for developer created Models. It also extends the Loader class, granting access to other Models, Libraries and Configuration Items, and also provides access to the Database class.
• Database The Database class returns singleton instances of database connections. Currently it returns a singleton PDO object. Developers must first supply connection configuration parameters to access this class. Multiple database singletons are supported via named instances.
• Loader The Loader class is a parent class for Controller, Model and Library classes. It provided a way to load singleton instances of Libraries and Models, as well as access to Configuration Items.
• View The View class takes an template file and an array of data and parses the template using the data array as variables. The View instance belongs to the Response object.
• Config The Config class provides a way to set or get configuration key->value pairs throughout the application.

Application Flow

When the PunyMVC->run() method is called, the following workflow is executed:

1. The PunyMVC object instances a Router object and a Request object and calls the Router->getRouteAction() method, passing along the Request object.
2. The Router inspects the Request to find a matching route, and returns an generic object back to the PunyMVC object, containing the path, class and method of the appropriate Controller.
3. The PunyMVC class instances the controller and calls its method, passing along the Request object and a new Response Object.
4. From here on is it up to the developer's code... The controller's parent Controller base class extends the Loader class, providing him with easy means to access models, libraries, and configuration items. As the Request and Response objects are required parameters of the Controller base class, the developer can also get Request information, and use the Response object to manipulate output such as sending response headers, setting raw output or executing views.
5. When the controller code is finished, either the developer can call the Response->send() method, or it will be called automatically via the Response object destructor. The Response object will build the response by setting the HTTP status code, outputting the response headers and finally the response body.
6. That's it!