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 . 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,. require_once('databaseobjects/' . $object . '.database.class .php& apos;); } else { require_once('objects/' . $object . '.class .php& apos;); } self::$objects[ $key ] = new $object(. 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