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 Now that we know more about what we are here to do, it is time to start planning our framework to ensure we get it off to the right start. In this chapter, you will learn: About design and architectural patterns in PHP, including: Model-View-Controller Registry Singleton How to structure an extendable framework How the framework should work with settings for the site and e-commerce setups it powers Let us start by designing our framework, and then building it based on our ideas for its design. Designing a killer framework There are many different ways to design and build frameworks. Some involve building very complicated frameworks, and others involve creating simple ones. In this book, we are going to quickly build an easy-to-use, easy-to-understand framework. This book will serve as a guide to help you develop a framework of your own, different from the one created in this book, but better suited to your needs, ideas, and preferences. The emphasis in this book is on e-commerce, so if you already have a framework of your own, or would prefer to use an existing framework, this book will give you ideas to integrate e-commerce capabilities into any framework. • ° ° ° • • 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 [ 20 ] Patterns There are a number of design and architectural patterns that were designed to help provide some general, good practices and solutions to common problems within software design. There are a few patterns of particular interest to us, as we are looking to develop a framework: Model-View-Controller (MVC) Registry Singleton Model-View-Controller (MVC) The Model-View-Controller architectural pattern provides a widely used solution to separate the user interface from the logic of an application. The user interface of the application (view) interacts with the data (model) using the controller, which contains the business rules needed to manipulate data sent to and from the model. To put this into an e-commerce perspective, consider a customer adding a product to their shopping basket clicks on an Add to basket button within the view/user interface. The controller processes this request and interacts with the model (basket) to add the product to the basket. Similarly, the data from within the basket is relayed back to the user interface through the controller, to display how many products are in the basket, and the value of the contents. CONTROLLER VIEW MODEL Because we are creating a framework for use with websites and web applications, we can further extend the representation of the MVC pattern to reect implementation in such a framework. As discussed earlier, the models represent data; this is primarily stored within the database. However, in our framework we will have a series of models, which take the data and store it within themselves in a more suitable format, or allowing the data to be manipulated more easily. So, we could in fact add our database to this diagram, to show the interaction with the models and the database. We are also viewing the end result of our website or web application in a web browser, which renders the views, and relays our interactions (for example mouse clicks or eld submissions), back to the controller. So we could also add the • • • 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 [ 21 ] web browser to the diagram, to show its interaction with the views. This gives us a clearer understanding of how the MVC pattern will work within our framework, and where the three components sit within it. CONTROLLER VIEW MODEL WEB BROWSER DATABASE Registry The registry pattern provides a means to store a collection of objects within our framework. The need for a registry arises from the abstraction provided with the MVC pattern. Each set of controllers and models we create (for example products, shopping basket, page viewing, or content management) need to perform some shared tasks, including: Querying the database Checking if the user is logged in, and if so, getting certain user data Sending data to the views to be generated (template management) Sending e-mails, for instance to conrm a purchase with the customer Interacting with the server's lesystem, for instance to upload photographs of products • • • • • 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 [ 22 ] Most systems and frameworks abstract these functions into objects of their own, and ours will be no exception. A registry allows us to keep these objects together. The registry can then be passed around the framework, providing a single point of contact to access these core functions. Let's have an overview of the registry pattern: DATABASE VIEWS FILESYSTEM DATABASE HANDLER TEMPLATE MANAGER EMAIL SENDER FILESYSTEM MANAGEMENT REGISTRY REST OF THE FRAMEWORK MAIL PROGRAM AUTHENTICATION HANDLER The framework interacts directly with the registry, which provides access to the other relevant objects. These objects can interact with one another using the registry itself, and have functionality to interact with aspects of the system they require; that is, the database handler can access the database, the template manager can access the templates stored on the lesystem, the e-mail sender can access the e-mail templates and also the systems mail program, the lesystem manager can access the lesystem, and the authentication handler reads and writes to session variables and cookies to maintain an authenticated user's session throughout their visit to the site. Singleton There are certain situations where we may require an object to only ever have one instance of it available. For instance, we will make use of a database handler and multiple instances of this could lead to results from different queries being supplied, depending on how it is used. The singleton pattern is designed to prevent this from occurring, by restricting an object to one instance only. However, we won't use the singleton pattern in this way. We will instead use it to ensure we have only one instance of our registry available in the framework at any point of time. This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010 953 Quincy Drive, , Brick, , 08724 . architectural patterns in PHP, including: Model-View-Controller Registry Singleton How to structure an extendable framework How the framework should work with settings for the site and e-commerce setups. emphasis in this book is on e-commerce, so if you already have a framework of your own, or would prefer to use an existing framework, this book will give you ideas to integrate e-commerce capabilities. 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 Now that we know more about what we are