Per-page basket If there is nothing in the customer's basket, they will be shown an empty basket message, like the following, on each page: • •... If the customer has products in their b
Trang 1Service subscription payments: These are generally similar to
one-click payments; you click on the subscription level, and then you pay
Most subscription services also make it easy to upgrade or downgrade
accounts at any point, resulting in the customer being charged pro-rata
based on how long their account was at each subscription level Subscription
sites give access to products or services for the duration of a subscription,
from a business perspective This often allows measurable recurring income,
and can reduce transaction fees For example, on a music download website,
the customer may wish to make 25 purchases a month, and each purchase
would incur a transaction fee With a subscription payment method, the
transaction fees apply to less regular, larger payments, which tend to work
out less overall
Auctions: Auctions lead to bidding for products This involves the customer
committing to purchase the product at a certain price, provided no other
customer commits to a higher price within the auction time window Often,
auction sites are automated, so the customer enters a maximum price, and
over the duration of the auction, the website will increase the customer's bid,
with respect to their maximum bid, as and when other bids come in
For our framework, a shopping basket is going to be the most appropriate
option; however, this is a framework After all, there is nothing stopping us from
implementing other methods of facilitating purchases
Our basket
At the end of this chapter, we will have a "shopping basket" page and a smaller
shopping basket displayed on each page
Per-page basket
If there is nothing in the customer's basket, they will be shown an empty basket
message, like the following, on each page:
•
•
Trang 2If the customer has products in their basket, the small basket message on each page
reflects something similar to this:
And, our main basket page should look like this:
Considerations for our shopping basket
We discussed a number of considerations we need to take into account within our
shopping basket in Chapter 4, Product Variations and User Uploads Let's recap on
those, and discuss how we shall implement those suggestions
Stock levels: In some cases, we need to determine if there is sufficient stock
when a customer adds a product to their basket When we add a product to
the basket, we can simply query the products database, and ensure the level
in stock is either more than the quantity the customer wishes to purchase,
or is not relevant for that product (for example digital delivery products,
services, and so on)
•
Trang 3Product variations: When a customer adds a product variation to their
basket, we need to record the variation that it is The way products are
maintained in an array for the basket must differentiate products and
product variants, to ensure that when a customer adds a second instance
of the product, the variant choices are preserved, allowing the customer to
purchase any number of any different variations of a product
Product customizations: If the customer customizes a product, we need to
record any customization data they have left, as with the product variations
Templates: We need a number of different templates to show the basket: an
empty basket, a summary of the basket on every page, and so on
Subtotals: We need to calculate subtotals for each product in the basket.
Creating a basket
Let us create our shopping basket in stages, starting with basic functionality,
and then extending it as we go along to support all of the considerations we
have discussed
When to build a user's basket
Our shopping basket will probably be stored on most pages, so we need to ensure
that we can build up the contents of a shopping basket regardless of where a
user is within the site being powered by our framework Obviously, we may not
always want to have this available, but more often than not, we would Another
consideration is with regards to user authentication: if the visitor is a logged-in user,
then the basket will be built in a different way, so we need to ensure we build the
basket after any authentication processing is done
Basket database
We looked at creating a wish list in Chapter 5, Enhancing the User Experience;
although the wish list was only suitable for standard products, which couldn't be
customized and didn't have variants The shopping basket needs to work in a similar
way to this A single database table is required that relates these products to the
customers Let's take the data from our wish-list table, and extend it to make it
more suitable for a shopping basket
•
•
•
•
Trang 4Field Type Description
ID Integer (Auto increment,
Primary Key) Session_id Varchar To relate products in the basket to customers
who are not logged into the site
User_id Integer To relate products in the basket to customers
who are logged into the site
Quantity Integer The quantity of the particular product that
the customer wishes to purchase
IPAddress Varchar This is also needed to help relate the products
in the basket to users who are not logged in
Timestamp Timestamp To maintain active and expired contents This
is primarily for customers who are not logged in; after a certain period of time, we need to assume that the session ID and IP address now belong to another customer
This database is represented with the following SQL code:
CREATE TABLE `book4database`.`basket_contents` (
`ID` INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
`session_id` VARCHAR( 50 ) NOT NULL,
`user_id` INT NOT NULL ,
`product_id` INT NOT NULL,
`quantity` INT NOT NULL,
`ip_address` VARCHAR( 50 ) NOT NULL,
`timestamp` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE = MYISAM;
Basket contents
We have a basket structure in our database, but we now need to allow our customers
to control the contents of the basket This involves allowing them to:
View the basket
Add products to their basket
Add customizable products to their basket
Add variations of a product to their basket
Edit quantities of products in their basket
Let's go through these requirements, and implement them into our framework
•
•
•
•
•
Trang 5Viewing the basket
This may seem strange, discussing viewing the basket before our customers are
even able to add products to the basket However, the reason for this is that we need
functionality in place for checking the basket contents before we can add a product
to the basket If a customer adds a product to their basket twice, the second instance
should increment the quantity of the first instance of the product, which means we
need to be able to determine if a product exists in the basket
The following stages are involved in checking our shopping basket:
1 Select relevant data from the basket table in the database
2 Build an array of data representing the contents of the basket
3 Set some variables, including basket cost, if the basket is empty, and that we
have checked the baskets contents
checkBasket method
We need a function that performs all of the aspects of checking the basket, so that we
can display the basket to our customers
/**
* Checks for the users basket contents
* @return void
*/
The first stage is to generate a number of variables to use later We indicate that the
basket has been checked, which prevents the framework from unnecessarily calling
this method again once it has already been called, and the data processed
We also need the user's session ID and IP address, primarily for customers who are
not logged in, and if the user is logged in, we need to get their username
public function checkBasket()
{
// set out basket checked variable - this is to prevent this
// function being called unnecessarily
// if we run this on page load to generate a mini-basket, we
// don't need to reload it to display the main basket!
$this->basketChecked = true;
// get user identifiable data
$session_id = session_id();
$ip_address = $_SERVER ['REMOTE_ADDR'];
// if the customer is logged in, our query is different
if( $registry->getObject('authentication')->