We need the structure to provide for: Models Views We may wish to integrate the ability to switch styles for the websites we power with our framework, so one folder for each unique set o
Trang 1The next important stage in the design of our framework is its structure We need
to design a suitable file structure for our framework We need the structure to
provide for:
Models
Views (We may wish to integrate the ability to switch styles for the websites
we power with our framework, so one folder for each unique set of
templates, styles, and views would be a good idea.)
Controllers (We may wish to have each controller within its own folder, as
we may have accompanying functions in additional files, so we can keep
them organized.)
Administration controllers (If we are to add administration tools to our
framework, we should provide some administration controllers These
would be controllers for the various models we have; however, they would
be designed for administrative tasks, and would be accessible only to
administrators.)
Registry
Registry objects
User/administrator uploaded files
Third-party libraries
Any other code
Taking this framework structure into account, a suitable directory structure would
be as follows:
Models
Views
View A (that is, a folder per set of views) Templates
Images JavaScript Controllers
Controller A (that is, a folder per controller)
ControllerA ControllerAAdmin
•
•
•
•
•
•
•
•
•
•
•
°
°
°
°
•
°
Trang 2Objects Database objects Assets
Uploads
To be expanded when we add products and images to our framework!
Libraries
Miscellaneous
Building a killer framework
Now that we have designed our framework, it is time to start building it! Let's start
by implementing the patterns we discussed earlier in the chapter
If we now look at an overview of our framework, the user visits the site through
the index.php file, which in turn instantiates the registry, creates or instantiates the
relevant controllers, and passes the registry to those The controllers in turn create
models where appropriate, and both the models and controllers can interact with
the registry (as it was passed to the objects), generating and manipulating views as
appropriate The following diagram illustrates this:
DATABASE HANDLER TEMPLATE MANAGER EMAIL SENDER MANAGEMENTFILESYSTEM
REGISTRY
CONTROLLERS
THE USER MODELS
AUTHENTICATION HANDLER
•
°
°
•
•
°
•
•
Trang 3Pattern implementation
There are a number of different ways to implement the patterns we discussed Many
different frameworks utilize these patterns, and implement them in a wide range
of different ways The way we are going to implement them is just one of these
methods You may find it best to alter this implementation to better suit your needs,
or perhaps this will provide you with a great structure to build your own framework
from Let us begin
MVC
The actual implementation of the MVC pattern at this stage is quite difficult, as
it essentially requires us to be at a stage where we wish to implement the main
features that the sites powered by our framework will use We are, of course, not
yet at this stage We only have our folder structure in place; however, we can create
some example or basic models, views, and controllers to illustrate its workings, or
alternatively we can create some interfaces for the models and views to ensure they
all have a certain, common structure for all of our models and controllers
Registry
The registry implementation is quite straightforward; the main difficulty is with
all of the objects it holds! The registry on its own is very simple It needs to have a
method to create certain objects and store them with a key; it needs another method,
which when passed with a key as a parameter, returns the object in question
We can also store some useful, central functions within the registry object itself;
although if we wished, we could abstract them into objects of their own (If you feel
your framework would be better suited with these functions being contained within
a separate object(s), please do so!) Such functions include:
Processing the incoming URL, so our index.php file can route the
request correctly
Building URLs based on a series of parameters, a query string, and the URL
display/generation method we use (that is whether we have mod_rewrite
enabled on our server, or not)
Pagination
Settings
The registry is our primary store for both settings and commonly used objects, so we
need to make provision for settings management
•
•
•
Trang 4Database stored settings in web applications often range from large text areas to
Boolean tick boxes This sort of flexibility isn't something we can easily add into the
database easily The simplest method is to store settings in a single table, consisting
of a key and setting value pair, with the setting value stored as longtext Sometext Some
settings could be stored within the code too The registry needs a simple method
to store a copy of these settings for the framework to use
Code
The code that follows makes up the basics of our registry, with two arrays:
one for objects, one for settings, and a store and get method for each of them
The storeObject method also has provisions to detect if the object is a database
object, and if so, it opens the object from a different folder
/**
* The array of objects being stored within the registry
* @access private
*/
private static $objects = array();
/**
* The array of settings being stored within the registry
* @access private
*/
private static $settings = array();
/**
* Stores an object in the registry
* @param String $object the name of the object
* @param String $key the key for the array
* @return void
*/
public function storeObject( $object, $key )
{
if( strpos( $object, 'database' ) !== false ) 'database' ) !== false )
{
$object = str_replace( '.database', 'database', $object);
require_once('databaseobjects/' $object
'.database.class.php');
}
else
{
require_once('objects/' $object '.class.php');
}
self::$objects[ $key ] = new $object( self::$instance );
Trang 5}
/**
* Gets an object from within the registry
* @param String $key the array key used to store the object
* @return object - the object
*/
public function getObject( $key )
{
if( is_object ( self::$objects[ $key ] ) )
{
return self::$objects[ $key ];
}
}
/**
* Stores a setting in the registry
* @param String $data the setting we wish to store
* @param String $key the key for the array to access the setting
* @return void
*/
public function storeSetting( $data, $key )
{
self::$settings[ $key ] = $data;
}
/**
* Gets a setting from the registry
* @param String $key the key used to store the setting
* @return String the setting
*/
public function getSetting( $key )
{
return self::$settings[ $key ];
}
Singleton
The singleton pattern is very easy to implement, as it requires only a few minor
changes to a standard PHP class, to ensure that it is only ever instantiated once
/**
* The instance of the registry
* @access private
*/
private static $instance;