PHP 5 e-commerce Development- P9 ppt

Chapter 2
[ 23 ]
Structure
The next important stage in the design of our framework is its structure. We need
to design a suitable le 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 les, 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 les
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
•
•
•
•
•
•
•
•
•
•
•
°
°
°
°
•
°


This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010
953 Quincy Drive, , Brick, , 08724
Planning our Framework
[ 24 ]
Registry
Objects
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 le, 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
VIEWS
MAIL PROGRAM
FILESYSTEM
DATABASE HANDLER
TEMPLATE MANAGER
EMAIL SENDER
FILESYSTEM
MANAGEMENT
REGISTRY
CONTROLLERS
INDEX.PHP
CONFIG.PHP
THE USER
MODELS

AUTHENTICATION
HANDLER
•
°
°
•
•
°
•
•
This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010
953 Quincy Drive, , Brick, , 08724
Chapter 2
[ 25 ]
Pattern 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 nd 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 difcult, 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 difculty 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 le 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.
•
•
•
This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010
953 Quincy Drive, , Brick, , 08724
Planning our Framework
[ 26 ]
Data
Database stored settings in web applications often range from large text areas to
Boolean tick boxes. This sort of exibility 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 );
This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010
953 Quincy Drive, , Brick, , 08724
Chapter 2
[ 27 ]
}
/**
* 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;
This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010
953 Quincy Drive, , Brick, , 08724