PHP 5 e-commerce Development- P15 potx

Other potential modules potential modules modulesWe could of course have many more objects managed with our registry; if we wished to further extend our framework in the future, this cou

Other potential modules potential modules modules

We could of course have many more objects managed with our registry; if we wished

to further extend our framework in the future, this could include:

E-mail parsing

Security management

Filesystem management

Let's have a brief look at what would be involved in such objects, and potential uses

for them

Email parsing

With an e-mail parsing object, we could easily process incoming e-mails This could

be useful for:

Running an online help desk: We could process incoming e-mails, and

log them as support tickets, even assign them to different categories or

departments depending on the e-mail address the e-mails were sent to

Running a basic online e-mail service for our customers

Security management

By providing a security management object within our registry, we could make it

easier to:

Manage a ban list of:

E-mail addresses Usernames

IP addresses (to prevent troublesome users registering, and make it easy to block automated spam bots)

Validate certain forms of data, including:

E-mail addresses Phone numbers Prices

Postal codes and zip codes

•

•

•

•

•

•

°

°

°

•

°

°

°

°

Filesystem management

Filesystem access could also be abstracted, making it easier for us to:

Create files and folders on the server

Manage permissions of files

Process uploaded files

Delete files

Display file and directory listings

This would be useful if we wish to add functions to make it easier to manage file

uploads; for instance when we integrate the provisions for allowing customers to

upload files with certain products (for example a photograph to be printed onto a

t-shirt they order), we could use this to easily manage the uploads, place the uploads

into monthly or weekly folders, and keep things easily organized

Routing requests

We now have our core tasks managed within a single instance of a registry, which

is available to the rest of the framework These core tasks are generally required for

each area of the site We also have a structure in place allowing different code to

be run, such as for a product to be displayed, an order to be placed, or a page to be

viewed While this additional code is easy to slot in, we still require a way for the

framework to know when that code should be run, based on the URL our users

are visiting

The simplest way to route requests is to first search for any pages in the database that

have a search engine-friendly reference that matches the incoming URL If no match

is found, we call the controller, which matches the first part of the URL, and have

it determine the correct action to take based on the rest of the URL For example,

products/view/some-product would tell the products controller to "view" the

product with the reference "some product"

This isn't the most flexible method, as we may want requests of certain formats to be

sent to different models, or be handled in a different way; however, it is the quickest

and easiest method One way to extend this is with a router

An alternative: With a router

An alternative approach is to use a router The router matches the pattern of the

URL of the visitor to the website and routes the request depending on the format,

or against a series of rules which are defined as routes

•

•

•

•

•

Try it yourself

Why not try and integrate a router into the framework yourself?

Processing the incoming URL within our the incoming URL within our

registry object

A single function allows us to easily process the current URL and breaks it down to

make it easy for us to route the request to the correct part of the framework

This function works by taking the URL path from the page GET variable (for

example, ?page=products/view/some-product) The framework is set to process

everything between forward slashes as a different part of the URL The first section,

for example products, indicates which controller to use Generally the controller will

take the second part, say view, to determine what it needs to do, and how it should

use data from the model, and often the third part as an indication as to the data the

model should represent

/**

* Gets data from the current URL

* @return void

*/

public function getURLData()

{

$urldata = $_GET['page'];

self::$urlPath = $urldata;

if( $urldata == '' )

{

$this->urlBits[] = 'home';

}

else

{

We split the URL data at each instance of a forward slash with the explode function

$data = explode( '/', $urldata );

while ( !empty( $data ) && strlen( reset( $data ) ) === 0 )

{

array_shift( $data );

}

while ( !empty( $data ) && strlen( end( $data ) ) === 0)

{

array_pop($data);

}

self::$urlBits = $this->array_trim( $data );

}

}

Two variables are required to store the URL and the bits of the URL as an array Two

additional functions are also required, to return the URL and the bits of the URL

index.php

Our index.php file needs to load up our registry, connect to the database, call

the authentication checks, process the URL, and pass control to the appropriate

controller—which is quite a lot of work Most of the actual work is done by the

registry and the registry objects we have already created

The first stage is to load the registry and its objects Once this is done, we can connect

to the database, and then we can perform our authentication checks Before any code

is written, we should start our sessions; this can't be done after anything has been

outputted to the user, so it's best to do it before any other code to make sure this is

the case

// first and foremost, start our sessions

session_start();

// setup some definitions

// The applications root path, so we can easily get this path from

files located in other folders

define( "FRAMEWORK_PATH", dirname( FILE ) "/" );

// require our registry

require_once('registry/registry.class.php');

$registry = PHPEcommerceFrameworkRegistry::singleton();

$registry->getURLData();

// store core objects in the registry.

$registry->storeObject('mysql.database', 'db');

$registry->storeObject('template', 'template');

$registry->storeObject('authentication', 'authenticate');

// database settings

include(FRAMEWORK_PATH 'config.php');

// create a database connection

$registry->getObject('db')->newConnection($configs['db_host_

ecomframe'], $configs['db_user_ecomframe'], $configs['db_pass_

ecomframe'], $configs['db_name_ecomframe']);

// process any authentication

$registry->getObject('authenticate')->checkForAuthentication();

Next we need to load a list of controllers our framework has (we should maintain

a database table of these) Once the registry object has parsed the URL the user is

accessing the site with, we can check the first part of this against our controller list,

and pass control to the relevant one

// populate our page object from a template file

$registry->getObject('template')->

buildFromTemplates('header.tpl.php', 'main.tpl.php',

'footer.tpl.php');

$activeControllers = array();

$registry->getObject('db')->executeQuery('SELECT controller FROM

controllers WHERE active=1');

while( $activeController = $registry->getObject('db')->getRows() )

{

$activeControllers[] = $activeController['controller'];

}

$currentController = $registry->getURLBit( 0 );

if( in_array( $currentController, $activeControllers ) )

{

require_once( FRAMEWORK_PATH 'controllers/'

$currentController '/controller.php');

$controllerInc = $currentController.'controller';

$controller = new $controllerInc( $registry, true );

}

else

{

require_once( FRAMEWORK_PATH 'controllers/page/controller.php');

$controller = new Pagecontroller( $registry, true );

}

// parse it all, and spit it out

$registry->getObject('template')->parseOutput();

print $registry->getObject('template')->getPage()->getContent();

exit();