-
Notifications
You must be signed in to change notification settings - Fork 16
Controller and OOP
In OOP we build classes following the principle of the single responsibility that states that every module or class should have responsibility over a single part of the functionality provided by the software and that responsibility should be entirely encapsulated by the class.
In this section, you will learn how to use the OOP inheritance and method overriding to handle, generalize, reuse and extend controller responsibility. Although all the following examples are focused on the Controller, all of the concepts inherent the OOP can also be applied to the development of the View and Model entities of WevMVC (which we will discuss later).
Like we showed in the previous example we can use the OOP inheritance to take the advantages of extending the "abstract responsibilities" of framework\Controller class to "custom and specialized responsibilities" of the concrete controllers\HelloWorld class. Now we will give you another example regarding another OOP feature: method overriding:
The main responsibility of a WebMVC Controller is to represent a callable interface from HTTP request and also to establish native cooperation with two external classes: View and Model. We will discuss them in depth later but, right now you must take into consideration that any time you invoke a controller from HTTP, its default, and automatic behavior is to connects a View to a Model. Then, automatically, WevMVC will show you the GUI design managed by the View.
If you want to see in action this behavior, first reconsidering the previous controller\HelloWord:
<?php
namespace controllers;
use framework\Controller;
class HelloWorld extends Controller
{
public function sayHello()
{
echo "Hello World";
}
}But now, instead of typing http://localhost/hello_world/say_hello, like we made in the previous example, just invoking HelloWord without any method by typing:
http://localhost/hello_world
By now we are requesting the execution of HelloWorld standard behavior and we will now obtain an exception:
framework\exceptions\NotInitializedViewException
Are you surprised? That happens because, by typing http://localhost/hello_world, we invoke the controller\HelloWord standard behavior built and inherited from its parent: the __construct() method defined into the abstract framework\Controller class. The parent __construct(), implements the following behavior: it uses a generic and null View when it does not have any reference to a custom instance of it. It does the same for the Model. But, when WebMVC tries to show the View it throws an exception because the design of a generic null View, by default, is not initialized. In the example, we have an uninitialized design because we are just echoing a message rather than using a GUI design.
Fortunately, by using the OOP method overriding we can build an extended version, we call it controllers\EchoController, of framework\Controller that will implement an "overridden" behavior with the purpose of avoiding the exception when we don't want use any GUI design. So, by developing this new version, we are going to be to override the standard parent behavior with the goal to create a hook to the View initialization because we haven't the need of using a GUI design.
Take a look at the following class:
<?php
namespace controllers;
use framework\Controller;
class EchoController extends Controller
{
/**
* @override __construct()
*/
public function __construct()
{
parent::__construct();
$this->hookViewInitialization();
}
/**
* A custom hook to initialize the View design.
* We use replaceTpl to initialize View design with null
*/
protected function hookViewInitialization()
{
$this->view->replaceTpl(" ");
}
}In this version, we override the standard parent behavior by building ad calling a hook to the View initialization, because we haven't the need of using a GUI design. You must don't take care, right now, of hookViewInitialization implementation. Simply you must consider that by calling it we are able to initialize the View avoiding the exception.
So with the availability of controllers\EchoController, in witch a GUI design is always initialized, we can now refactor the previous controllers\HelloWorld in this way:
<?php
namespace controllers;
use controllers\EchoController;
class HelloWorld extends EchoController
{
public function sayHello()
{
echo "Hello World";
}
}//TODO
In the previous section, we speak about the principle of the 'single responsibility' and how extends and overrides a controller responsibility with OOP.
However, when we are building a controller class, having the goal of managing a complex web page, we could involve different computational tasks inside a controller and be being compliance to this principle can be hard.
WebMVC offers you its built-in controller autorun behavior. for making even easier the task of extending "abstract responsibility", commonly designed into the controller object constructor for an automatic execution.
With 'controller autorun' you have the ability to automatically execute some custom code, even located outside the controller constructor, after controller object creation. You can also potentially write and override the autorun code for extending and override the controller behavior that must be executed automatically. In others words, you can think autorun like an event that is generated after a controller object creation. So you can handle this event in any child controller, to extend the basic responsibility of a parent one without the need to override the parent constructor.
The examples below will show you the facilities using the autorun method.
First, to make a better representation of a controller main responsibility, we need to refactor, in the code below, the previous controllers\HelloWord. We now override __construct to enable the automatic execution of its main responsibility, which is simply to show the message "Hello World main responsibility". Do not take care, right now, of unsetView method. We just coded this hook to disable the default behavior of a controller which is to interact automatically with a View entity (we will introduce it later).
<?php
namespace controllers;
use framework\Controller;
class HelloWorld extends Controller
{
public function __construct()
{
parent::__construct();
$this->unsetView();
echo "HelloWorld main responsibility";
}
/**
* A custom hook to disabling the interaction with a View
*/
private function unsetView()
{
$this->view->replaceTpl(" ");
}
}Now, suppose we want to have a "extended" version of controllers\HelloWorld coded by controllers\HelloSecond class. HelloSecond must inherit HelloWorld main responsibility, that is showing the message "Hello World main responsibility". We also desire that HelloSecond main responsibility is simply represented by showing an additional new line with the message "HelloSecond main responsibility". Finally, as additional behavior, HelloSecond must show in a new line an additional message, "Hello Message from HelloSecond controller".
To achieve this goal, thanks to the OOP, we can simply override the Home __construct like this:
namespace controllers;
use controllers\Home;
class HelloSecond extends HelloWorld
{
/**
* @override __construct()
* Show and additional message after a new line
*/
public function __construct()
{
// Inherit parent responsability
parent:__construct();
// Extending parent responsibility by adding its own one
echo "<br>" . "HelloSecond main responsibility";
// Adding a custom behavior
echo "<br>" . "Hello message from HelloSecond controller";
}
}By requesting http://localhost/hello_second output will be:
HelloWorld main responsibility
HelloSecond main responsibility
Hello message from HelloSecond controller
In this case, simply by extending HelloWorld and by overriding its __construct we can well perform the task. But what if, having now the need to extend HelloSecond to HelloThird, while having to inherit its main responsibility but also the need to replace the specific behavior of showing the "Hello message from HelloSecond Controller" message with a new one like "Hello message from HelloThird Controller"?
By using OOP extension and overriding __construct, like we made for HelloSecond we can't do the job.
In fact, by coding:
namespace controllers;
use controllers\Home;
class HelloThird extends HelloSecond
{
/**
* @override __construct()
* Show and additional message after a new line
*/
public function __construct()
{
// Inherit parent responsability
parent:__construct();
// Extending parent responsibility by adding its own one
echo "<br>" . "HelloThird main responsibility";
// Adding a custom behaviour
echo "<br>" . "Hello message from HelloThird controller";
}
}and by requesting http://localhost/hello_third output will be:
Hello World
HelloSecond main responsibility
Hello message from HelloSecond controller
HelloThird main responsibility
Hello message from HelloThird controller
The unwanted message "Hello message from HelloSecond controller" will appear. That's why we put a custom behavior into the constructor just for the need we want to have it automatically when instantiating the controller.
Fortunately, by using autorun method we can easily reach the goal.
Refactor the code of HelloSecond and HelloThird like:
namespace controllers;
use controllers\Home;
class HomeSecond extends Home
{
/**
* @override __construct()
* Show and additional message after a new line
*/
public function __construct()
{
// Inherit parent responsability
parent:__construct();
// Extending parent responsibility by adding its own one
echo "<br>" . "HelloSecond main responsibility";
}
/**
* @override autorun($parameters = null)
*/
protected function autorun($parameters = null)
{
// Adding a custom behavior
echo "<br>" . "Hello message from HelloSecond controller";
}
}namespace controllers;
use controllers\Home;
class HomeThird extends Home
{
/**
* @override __construct()
* Show and additional message after a new line
*/
public function __construct()
{
// Inherit parent responsability
parent:__construct();
// Extending parent responsibility by adding its own one
echo "<br>" . "HelloSecond main responsibility";
}
/**
* @override autorun($parameters = null)
*/
protected function autorun($parameters = null)
{
// Adding a custom behavior
echo "<br>" . "Hello message from HelloSecond controller";
}
}//TODO - ONLY NOTES
"Bootstrap" mobile version of the previous page. So we do the job simply by extending the controllers\Home.php and by creating controllers\HomeBootstrap.php in which we override autorun to instructing the controller to load a different design.
See the code below:
namespace controllers;
use controllers\Home;
class HomeSecondod extends Home
{
/**
* @override autorun($parameters = null)
*/
protected function autorun($parameters = null)
{
/**
* Replaces the GUI template of the parent with a Bootstrap
* mobile template coded into templates/home.bootstrap.html.tpl
* We used loadCustomTemplate method provided by framework\View
*/
$this->view->loadCustomTemplate("templates/home.bootstrap");
}
}Now we use Bootstrap for the mobile template of GUI. Note that it is ineffective on the server-side code developed so far thanks to the features of WebMVC that isolate client-side technologies in external template files
<!DOCTYPE html>
<html>
<head>
<title>Site Home Page</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<!-- Bootstrap core CSS -->
<link href="http://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/3.3.4/css/bootstrap.min.css" rel="stylesheet" media="screen">
</head>
<body>
<h1>Welcome to the site HomePage</h1>
<!-- Bootstrap and jQuery core JS -->
<script src="http://cdnjs.cloudflare.com/ajax/libs/jquery/2.1.3/jquery.min.js"></script>
<script src="http://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/3.3.4/js/bootstrap.min.js"></script>
</body>
</html>Now run by typing:
http://localhost/home_bootstrap
You should see the bootstrap mobile version of the homepage