Controllers form the entry point into your application. It handles requests by loading a controller class and the respective method.

It is from here that you can call your model classes, libraries and load the view files, among other things...

<?php namespace Controllers;

use Gliver\View\View;

class HomeController extends BaseController {

     *Load the home page.
     *@param null
     *@return void
    public function getIndex()
        //get the ending date today



All controller classes reside in the application/controllers directory or subdirectory:


One file can only contain one controller class.

Controller class files must have a .php file extension and the name of the controller class must be the same as the name of the file:

HomeController class resides in HomeController.php

Controller classes and file names must have the 'Controller' suffix as: HomeController.

When accessing controllers from a url, you only specify the controller name without the 'Controller' suffix as:


All controllers classes must extend the BaseController class.

class HomeController extends BaseController 

Ensure you namespace your controllers, so that they are autoloaded as expected.

If your controller class resides in the application/controllers directory then use:

namespace Controllers;

If your controller resides in a subdirectory like 'Admin' as application/controllers/Admin then use:

namespace Controllers\Admin;  

This follows psr-4 namespace pattern.

You cannot create static methods or properties in your controllers.

In order to use another class from the inside of your controller class, use the use statement with the full namespace of the class as:

use Helpers\View\View;

Do that to load the view helper class then access it from anywhere within your controllers as:


When defining your methods in your controllers, you can choose to let all your methods have unique names or you can use the same method name to excecute different methods based on the request method used.

There are two request methods that would be detected by Gliver framework : GET and POST methods.

With this feature comes a cool ability of Gliver to load a controller method based on your request method. This means that you can use the same method name in different request methods. For example:

Say you have a LoginController and would like to use the same method name for loading a login form and at the same time processing user login information - you will do this as below.

Create two methods named:

public function getLogin()


public function postLogin()


You will access both methods with the same url as:


Accessing this url in your address bar will load the user login form as the request method would be GET and the getLogin method would be excecuted.

Once the user fills up the form, you specify in your action attribute the same url for form submission as:

<form action="http://localhost/myapp/login/login" method="post" > 

When the user then submits the form, Gliver would detect this as a POST request and therefore submit your form to the postLogin() method of the LoginController.

So, there you go. Using the same method name to excecute different methods depending on the request method.



The view class enables you to provide a response to the url request.

This can be by loading html view files, sending pdf, json or xml responses.

To use the View loader, first require it in your controller class as:

use Gliver\View\View;  

You can then access the View class and methods directly without creating an instance.

All view files resides in the application/views directory and must have a .php file extension.

First instance, let's say you want to load the users.php view file in the home subdirectory, you'd do this:


If you want to pass some variables to be available to the view files, pass them in an array as the second parameter.

View::render('home/users', $data); 

Say you would like to dynamically get the site title from the controller and use it in your view file.

Create a $data array and store the value of the title as a key in the $data array, then then pass it as a second parameter to the View::render() method:

$data['title'] = "Gliver - Official Site"; 

View::render('home/users', $data);

You can then access it in your view file as:

<?php echo $title; ?>


If you want to return a json object instead of loading a html file, then use the renderJson method instead.

This method sets the content header as application/json.

Supply the array to be converted to a json object as an optional parameter as shown:



Out of the box, Gliver has an in built templating engine that abstracts the most commonly repeated actions when generating a view.

You do not need to specify a special file extension to activate the template engine. It is on by default.

The following template methods are available within the view files.


In regular PHP in order to echo a string to the browser, you open and close PHP tags then use the echo statement in between the tags:

<?php echo $username; ?> 

Gliver has a template method that does the same thing. Just put the variable to be printed within double curly braces.



This template method enables you to load view files that are shared as subviews.

You call this method from within your view files, while passing the name of the view file to be included as the first parameter.


If the view file to be included exists in a sub directory, specify the directory structure separated by forward slash.


Say you have a header.php and footer.php view files in your admin directory and would like to include them in your home.php view page.

This is what the code in your home.php file would look like

<div class="container">
    <div class="row">
        <div class="col-lg-12">




There are 3 ways you could use the @if method.

This depends on the type or length of the loop you want to execute.

The 3 code samples below demonstrate the different uses of the @if methid in the Gliver template view files.


@if(isset($email) AND ! empty($email))
  <p>Your email address is {{$email}}</p>


@if(count($users) > 0)
  <p>Registered users: {{count($users)}}</p>
  <p>There are no registered users yet!</p>


@if($score > 80) 
  <p>Grade : A  Remarks : Excellent</p>
@elseif($score > 60)
  <p>Grade : B  Remarks : Good </p>
  <p>Grade : C  Remarks : Fair</p>


@while($number <= 10)
  #do something to end this loop...


@for($itr = 1; $itr < 10; $itr++)
  <p>This is paragraph number {{$itr}} </p>


@foreach($users as $user)
  <p>Name {{$user['first_name']}} : Email : {{$user['email_address']}}</p>


Models help you handle database or API connection operations.

Models reside in the application/models directory or subdirectory and must extend the Model class.

<?php namespace Models;

class UsersModel extends Model {

   *@var string Table name 
  protected static $table = 'users';

All Model methods are declared as static.

<?php namespace Models;

class UsersModel extends Model {

  public static function getUsers()
    #... code goes here



Model classes and file names can optionally have the 'Model' suffix.

When accessing models classes specify the complete name without omiting the 'Model' suffix.

If your model class resides within a subdirectory like application/models/Admin use the correct namespace.

namespace Models\Admin; 

In order to use a model in your controllers, require the model using its full namespace.

Say you have a UsersModel that has a static getUser() method that returns the list of all users from the database.

This is how you access this method from the HomeController class.

use Models\UsersModel;

class HomeController extends BaseController {

  public function Queue()
    //get all users
    $data['users'] = UsersModel::getUsers();

    #... other code


More information is coming on how to use the Query Builder and Gliver ORM...

Error Handling

Error handling in Gliver comes in two flavors - either through PHP errors or Exceptions.

When writing, testing and deploying your application you are going to break something

Informative error information is a very quick and effective way to troubleshoot and fix problem code.

All errors encoutered in your application are logged into the error.log file found in:


You can also choose to display these errors on the screen, a good idea if you are in development mode, or to hide them when in production mode.

Turn error display on or off in the config.php file by either specifying the dev parameter to true or false:


Even if you turn error display off by setting dev->true, error messages will still be logged in the error.log file.

So, when an error occurs a template error page is shown to the user without any idetifying information. No error code or anything like that.

In order to find the particular error message, you'll need to open up the error log file and proceed from there.

"dev"=> true, is good for production mode to avoid exposing your application or server directory structure to a malicious jerk.

You might however want to create custom error messages that might be more sensible to your users - who may not be techies...

In that case use Exceptions

Write your code within a try...catch block.

Create your own Exception class by extending the exceptions class so that you have access to all the already in built functionality in the exception class.


In order to make use of this class, throw exceptions by passing the custom error message in this manner throw new BaseExceptionClass("...your error message here..."); then catch this in a block and display the error message by calling the errorShow() method like so: