Filtering products

Filtering products Another useful way to allow customers to better find the products they are looking for is with filtering.  Customers can filter down lists of products based on attributes, such as price ranges, manufacturer, weight, brands, and so on. Price range filtering should be simple enough. However, with attributes such as manufacturer or brands, we would need to extend the database and models representation of a product to maintain this additional information, and allow  us to filter down based on these attributes. There are a few different ways in which we can store filtered results: In the user's session: This will be lost when the user closes their browser. In a cookie: This information will stay when the user closes their browser. In the URL: This would allow the customer to filter results and send the link of those results to a friend. In POST data: The information will only be stored for the one instance the filter is used. Let's try using the URL to store filter data. If we format filter data within the URL as filter/attribute-type/attribute-value-ID, then we can simply iterate through the bits of the URL, find bits containing filter, and then take the next two parts of the URL to help build the filter. This way we can filter down products based on a number of attributes, for example filter/price/5/filter/weight/6. Of course, there is a limit to this, and that is the maximum length of a URL. 

Stock control

Stock control With product variations, stock control becomes an interesting issue. If we only had a single set of variations for each products (as we discussed under the Simple variants section, earlier in the chapter), we could simply disable an option if it was out of stock. However, with multiple variations we may have small blue t-shirts, but not large blue t-shirts. The logic for detecting if this is in stock obviously lies with the shopping basket itself: when we click on Add to basket, it will need to detect to  see if there are any in stock. This obviously isn't an ideal situation; however, an alternative would be to utilize AJAX to enable the view to alert the customer that a particular combination is out  of stock, by performing a lookup as and when the customer selects their variation of the product.

Product Variations and User Uploads

Having a store with products and categories is great, but we need to be able to offer greater flexibility with our products. We looked at how to extend the information stored about our products, and extending products that way; but certain types of product, like apparel, need to allow the user to customize the product, often by selecting a variation of the product, or uploading images or text as part of the  order. In this chapter, you will learn: How to create customizable products How to assign uploaded files to individual product orders How we will maintain these uploads How to assign custom user-submitted data with individual product orders One important point to note is that this chapter links in greatly with Chapter 6,  The Shopping Basket; so some aspects of this chapter may be preparation for that, and some aspects of that chapter may require some looking back at this one. This chapter will primarily focus on integrating support for these customizable products to our framework as it is at the moment. Giving users choice Many products in e-commerce stores require some sort of choice from the customer, be it the size, color, or even the material. At the moment, we only have very basic products, which can simply be viewed by our customers. We need to extend this to allow customers to see variations of products, and to be able to choose their own variation of the product, before purchasing it. 

.htaccess file

We have our index.php file set up to process the incoming request and send it to the relevant controller. However, URLs which have the format of index. php?page=some/page/on/our/site or index.php?page=products/view/someproduct are not as attractive or memorable as those with just some/page/on/our/ site or products/view/some-product. With the Apache module mod_rewrite we can get our site to rewrite the more friendly URLs into the less friendly ones for our framework to understand.
ErrorDocument 404 /index.php DirectoryIndex index.php <IfModule mod_rewrite.c>  RewriteEngine on  RewriteCond %{REQUEST_FILENAME} !-f  RewriteCond %{REQUEST_FILENAME} !-d  RewriteRule ^(.*)$ index.php?page=$1 [L,QSA] </IfModule> This .htaccess file instructs the web server (Apache) to use index.php as the index file within a directory. It also instructs Apache that if the mod_rewrite module is enabled, the requests that are not for valid files or directories should be rewritten to the main index.php file. However, anything that occurs after the directory containing the .htaccess file, should be appended to the page $_GET variable. For example, oursite.com/pagea would be rewritten to oursite.com/index. php?page=pagea.

Extending the database

Extending the database object So, how could we extend the database object, and the way we have designed it? Inheritance: We could have a database interface, which defines some base methods for any database object we create, making it easier to swap the type of database we use (for example, from MySQL to pgSQL, or MSSQL). Abstracting the logic to the queries: To further simplify the use of various database engines, we could abstract the logic from our queries into the database object itself. This way, instead of passing queries to the object, we pass the make up of the queries—for example, table, fields, fields to order by (to define how the results should be ordered), types of joins, and so on—and the object inserts every bit of SQL that is required. This is the only true way to have complete database abstraction within a framework. Debug information: We could add provisions for logging the performance of our queries, recording slow queries to allow us to debug, and optimize the queries we use.

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 reflect 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 field submissions), back to the controller. So we could also add the
• 

Why use e-commerce?

Why use e-commerce? The popularity of online shopping has increased dramatically over the past few years. Not only does it provide the convenience of allowing customers to shop in the comfort of their own home, it also allows businesses to trade on a global marketplace, targeting even more potential customers. Because everything is done electronically, e-commerce stores can also help generate recurring revenue, by recommending new products to customers based on previous purchases, and  by keeping them up to date with the store's catalog. Rolling out your own framework Throughout the course of this book, we are going to build a framework of our own, using PHP, as opposed to making use of an existing product. Sometimes, it is more appropriate to use existing solutions; sometimes it is better to use your own solutions. As you are reading this book, hopefully you know why you want to create your own framework. However, let's look at why we are going to create ours. Why PHP? PHP is a very popular language, and because it isn't a framework in its own right, we can easily structure our framework out of it, however we wish. The main choice for a programming language is generally down to your own preference. Most modern web hosts support PHP and MySQL, and while languages like  Ruby on Rails are gaining popularity, at the moment hosting for them is not as common. This book assumes that you already have a reasonable understanding of PHP, so hopefully that will also be an important factor in why you want to use PHP; perhaps you need to develop something quickly, and don't want to use a language or platform that is out of your comfort zone. Why a framework? Instead of looking to create an e-commerce system, designed to perform all types of e-commerce tasks, we will create a framework. This will make it easy to extend the needs of any e-commerce project with minimal effort. Because we are creating our own framework, it is going to be something we will know and understand very  well, meaning that if we do need to extend it or use it, we can do so easily.