Simply put, the role of the controller is to accept requests. It uses the get method, in this case via URI, to load a function module to refresh or submit a presentation layer. The controller will use the $_GET automatic global variable to determine which module to load.
An example of a request would look like this:
http://example.com/index.php?module=login
This seems simple, but in the implementation process it is not. Here are the argument parts that can be recognized by several controllers:
module defines which module to use, such as users. Module class defines which functional class to use, such as whether you want users to log in or log out.
event defines which specific event to use.
A more complex example can explain the request URL that is ultimately composed of each argument above:
http://example.com/index.php?module=users&class=login.
This request tells the controller that it should Load the users module, then the login class, and finally run the login::__default() default event because no specific event is defined.
The following is the specific code part:
<?php
/**
*index.php
*
* @author Joe Stump ＜ [email protected] ＞
* @copyright Joe Stump ＜ [email protected] ＞
* @license http://www.opensource.org/licenses/gpl-license.php
* @packageFramework
*/
require_once('config.php');
// {{{ __autoload($class)
/**
* __autoload
*
* Autoload is ran by PHP when it can't find a class it is trying to load.
* By naming our classes intelligently we should be able to load most classes
* dynamically.
*
* @author Joe Stump ＜ [email protected] ＞
* @param string $class Class name we're trying to load
* @return void
* @packageFramework
*/
function __autoload($class)
{
$file = str_replace('_','/',substr($class,2)).'.php';
require_once(FR_BASE_PATH.'/includes/'.$file);
}
// }}}
if (isset($_GET['module'])) {
$module = $_GET['module'];
if (isset($_GET['event'])) {
$event = $_GET['event'];
} else {
$event = '__default';
}
if (isset($_GET['class'])) {
$class = $_GET['class'];
} else {
$class = $module;
}
$classFile = FR_BASE_PATH.'/modules/'.$module.'/'.$class.'.php';
if (file_exists($classFile)) {
require_once($classFile);
if (class_exists($class)) {
try {
$instance = new $class();
if (!FR_Module::isValid($instance)) {
die("Requested module is not a valid framework module!");
}
$instance->moduleName = $module;
if ($instance->authenticate()) {
try {
$result = $instance->$event();
if (!PEAR::isError($result)) {
$presenter = FR_Presenter::factory($instance->presenter,$instance);
if (!PEAR::isError($presenter)) {
$presenter->display();
} else {
die($presenter->getMessage());
}
}
} catch (Exception $error) {
die($error->getMessage());
}
} else {
die("You do not have access to the requested page!");
}
} catch (Exception $error) {
die($error->getMessage());
}
} else {
die("An valid module for your request was not found");
}
} else {
die("Could not find: $classFile");
}
} else {
die("A valid module was not specified");
}
?＞
The following are the specific comments on the above code:
load "config.php"
to define the __autoload() function. This is a new function in PHP5, which facilitates dynamic loading of various classes.
If an argument is defined, then the relevant modules, classes and specific events are loaded,
followed by some judgments and specific error operations.
Finally, after everything is correct, the presentation layer
[friendly URL]
is loaded.If you think the request URL mentioned in the above example is If it makes you feel uncomfortable, then use mod_rewrite to implement friendly URLs. Next is the actual rewriting standard code written by the author for this framework:
RewriteEngine On
# Change the URI here to whatever you want your homepage to be
RewriteRule ^/$ /index.php?module=welcome [L,QSA]
# Changes / index.php?module=welcome to /welcome
RewriteCond %{DOCUMENT_ROOT}/
%{REQUEST_FILENAME} !-d RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule ^/([^/]*)$ /index. php?module=$1 [L,QSA]
# Changes /index.php?module=users&class=login to /users/login
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-d
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule ^/([^/]*)/([^/]*)$ /index.php?module=$1&class=$2 [L,QSA]
# Changes /index.php?module=users&class=login&event =foo
# to /users/login/foo.html
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-d
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule ^/([^/]*)/( [^/]*)/([^/]*).html$
/index.php?module=$1&class=$2&event=$3 [L,QSA]
Extending the Controller
[Extended Controller]
has a centralized controller One of the advantages is that after you add some functions, they can be reflected immediately through the controller. Here are a few ideas for extending this controller to make the framework more powerful overall:
You can use SoapServer, a new thing in PHP5, to automatically detect whether a request is SOAP.
You can use controllers to filter all automatic global variables such as $_GET and $_POST to prevent malicious HTML code, etc.
You can use controllers to convert expressions on the fly. Layer, for example, from the default mode to PDF mode
, you can directly add the caching mechanism in the controller. The advantage of this is that the entire application can use the cache to improve efficiency.
Of course, one thing to note is that you are in the controller. The added functionality will be reflected in the overall program. For example, you want to filter all automatic global variables, but many application administrators need to use some HTML code, which becomes a tricky thing (Translator's Note: My idea is to add an if conditional statement to load a specific module without applying the filtering function).