In php controller 4, the controller is used to accept requests. It uses the obtained method. here, a function module is loaded through URI to refresh or submit a presentation layer. The controller uses the $ _ GET automatic global variable to determine which module to load.
An example of a request looks like this:
Http://example.com/index.php? Module = login
This seems simple, but not in the implementation process. Here is the argument part that several controllers can recognize:
Module defines which module to use, such as the users module
Class defines which function class to use, such
Event defines which specific event to use
In this more complex example, we can explain the final request URL composed of each argument:
Http://example.com/index.php? Module = users & class = login
This request tells the controller to load the users module, followed by the login class, and finally runs the default login :__ default () event because no specific event is defined.
The code is as follows:
<? Php
/**
* Index. php
*
* @ Author jostump <joe@joestump.net>
* @ Copyright jostump <joe@joestump.net>
* @ License http://www.opensource.org/licenses/gpl-license.php
* @ Package Framework
*/
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 shoshould be able to load most classes
* Dynamically.
*
* @ Author jostump <joe@joestump.net>
* @ Param string $ class Class name we're re trying to load
* @ Return void
* @ Package Framework
*/
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 ("cocould not find: $ classFile ");
}
} Else {
Die ("A valid module was not specified ");
}
?>
Next is the specific comments of the above code:
Load "config. php"
Define the _ autoload () function. This is a new function in PHP5 to facilitate dynamic loading of various classes.
If an argument is defined, load related modules, classes, and specific events.
Next, let's take a look at some specific judgment and error operations.
After all the information is correct, the presentation layer is loaded.
Pretty URLs [friendly URL]
If you feel uncomfortable with the request URL mentioned in the above example, use mod_rewrite to implement friendly URLs. The following is the actual 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]
One advantage of having a centralized controller is that you can immediately use the controller after adding some features. The following are some ideas that can expand the controller to make the overall capabilities of this framework more powerful:
You can use a new thing SoapServer in PHP5 to automatically detect whether a request is SOAP
You can use the controller to filter all automatic global variables such as $ _ GET and $ _ POST to prevent malicious HTML code.
You can use the controller to instantly convert the presentation layer, for example, from the default mode to the PDF mode.
You can directly add a Cache mechanism to the controller. the advantage is that the entire application can use the cache to improve efficiency.
Of course, you must note that the functions you add to the controller will be reflected in the global program. If you want to filter all the automatic global variables, but many application administrators need to use some HTML code, it becomes a tricky thing (note: my idea is to add an if condition statement without applying the filter function when loading a specific module ).
