Tri 3 Project for Advanced Programming

Goals:
1. Use a database to store and update information that can be queried
2. Use PHP to talk to the database and to return some HTML or information
3. Optional: use the fetch API to talk to the server and update the page WITHOUT a REFRESH. If
you don't use fetch, then you will have a series of pages that work together to accomplish this.

You own a store (with two locations) that sell a variety of items. You must have at least 5 different
items to sell (perhaps not all items are in stock at both stores…but you need at least 5 different types
of items altogether). You get to choose the names, prices, descriptions, and images for these items.
You will want to find and download an image for each product. Save the images to an "images"
folder in your project folder (create a separate folder for this project and all files for this project). I'd
advise you to give the images short, easy to work with names. I'd also advise you to size/resize the
images so that they are all roughly the same size.

You should also give your store a name (e.g. Widgets R Us). Your site should prominently
display the company name at all times (perhaps just a banner at the top). Consider having a
menu system at the top of your pages (or page).

Database Design
You need to be able to track/store/work with the following information. I'd recommend 3 tables.

Items Each item has (in addition to a unique id or key):

● a name (ideally unique, to avoid confusion as we do this)
● a description (keep the description short, but not too short…at least 25 words, less than 100)
● a price (some positive decimal that represents a price in $, e.g. 4.99 or 0.25 or 8.00)
● an image filename: just the name of the file (which should correspond to an actual image saved
on your server)

Stores Each store has (in addition to a unique id or key):

● an address
● a phone number
● a manager (just a person's name...use different names for different stores)

Items to Stores Map/Linking Table You also need to be able to relate products to stores, and indicate
quantities. There are no unique keys here. You need to be able to track information like:
● Store 1 has 20 of Product A
● Store 2 has 8 of Product A
● Store 1 has 0 of Product B
● Store 2 has 5 of Product B
● etc.

Features on the Page/Site

Your site should allow users to do the following (see below). You get to organize how this flows on the
page(s), but each feature should be supported. There should be some "main page" or starting page;
the main page should be named index.html (or index.php). You get to determine how the rest of the
elements work from there (e.g. a menu system on each page). If you are going with separate pages,
there should be common menu items at the top of each page. If you are using fetch, then the menu at
the top (probably) shouldn't change.
A user should be able to do the following.
● A user should be able to get information for all store locations via some menu item (like a
"Locations" menu item, or "Stores" item). This should simply show the locations and the relevant
data for each store (address, phone number, manager name). This can be formatted as a
simple list or a grid (or some other option…have fun with it). This can be simple text with some
HTML for formatting. Note that this isn't showing the store's inventory.

● A user should be able to search for a product by typing a name or term into a "Search" feature.
Somewhere on the main page, the user should be able to type in a search term. How that
"search feature" flows is up to you. However, entering a search phrase should return a list of
products that "match" the search term (we are searching here by the product names, not
anything in the description). This list of products could be a simple list of names or it could be a
more complicated list (names, prices, images, etc.). When you click on a product from this view,
it should take you to the "Individual Product View" (see below). If the search term entered by
the user does not match any products in the database, then return a "nothing found" message.

● A user should be able to view the details of an individual product. Let's call this "Individual
Product View". This should show the name, description, price, and image for the product. Each
product needs to use the same layout or presentation structure (image here, description there,
price over here, etc.). This page should also show a list of stores and quantities available at
each store; e.g. "5 available at San Marcos". If a store has 0 in stock, you can show that
quantity as 0, but you should also call some attention to the fact that the product is out of stock
at that particular location (perhaps just a color change, or an extra icon to denote "out of stock").

This should not change anything in the database.

There should also be a "purchase" button. This button, when clicked, should direct you to the
"purchasing a product" process (see below).

● A user should be able to see a list of all products. Let's call this "All Product View". This can
be a menu item, something like a "View All Products", "View All", etc. link. This view should
show the name, price, and image for each product, perhaps displayed in a list or a grid (what a
fun time to revisit a flex layout!). You don't need to show the product's description on the "All
Product View" as it might make the formatting of the page a bit intense or bulky. For this view,
the images should be normalized so that they are the same size; format the images so that your
display looks consistent for all products. Each product should also have a link that takes them to
the "Individual Product View" for that particular product.

● A user should be able to purchase a product. Let's call this "purchasing a product". From the
"Individual Product View", there should be a link or a button that leads to this process. You
don't have to do a shopping cart; you will only support purchases of single products. Purchasing
a product involves the following details.
● The user must specify a quantity and a store. This can be done via checkboxes, radio
buttons, number sliders, select menus (drop down menus), users entering input from the
keyboard, etc. You get to pick how this information is specified, but both the number and
the store need to be specified. If you allow the user to type in the number and/or store
name, then you need to handle bad input gracefully (e.g. if they enter a non-number for
 the quantity, you should identify the problem and inform the user that they need to enter
numbers). This issue can be completely avoided by using a range input for the quantity
and radio boxes for the store name; don't let the user type information and they can't
mess it up (force them to make a selection and only provide valid options).

● Based on the selected product's price and the quantity, you should display the total price
for the user. This needs to be done before they confirm (or cancel) the purchase. You get
to decide how to do this. We are going to ignore sales tax (let's pretend we live in
Oregon or something). If the user updates the quantity, the total should also update.

● The user should get a chance to confirm or cancel the transaction; selecting a store and
a quantity is not enough. After seeing the total for the order, they must either "purchase"
or "cancel" (you can change the verbiage there if you like). Confirming the purchase
could be accomplished with a simple "Purchase Now!" button; canceling could be
accomplished with a button or by simply closing the page (if the order is canceled, the
store's inventory should not change…the store's inventory should only change if they
confirm the purchase, but see below for one more requirement). The "Purchase Now"
button (or whatever mechanism you choose) should not be an option unless a store and
a quantity have been chosen/specified/defaulted.

● If the user confirms the purchase of the product:

○ If the store has the desired quantity (or more), then the store's inventory should
get updated to remove the desired quantity (the database should get updated to
reflect the new quantity). No actual money will transfer hands...don't ask for
money! There should be some "confirmation" message that informs (or
congratulates) the user on their purchase; there should be a brief summary on
this page that restates the quantity purchased and the location it was purchased
from.
○ If the store does not have enough items, display an error message to the user
indicating that the store does not have the desired amount, that the transaction
has been canceled, and that they can reorder a new amount or change the order
to a different store (or, you could have the "are there enough items in the store"
logic implemented earlier when they are selecting the quantity/store…but at
some point, this should be handled).

● If the user cancels the purchase via a "Cancel Order" button, then the user should be
informed that the transaction was canceled. No changes should be made to the
database in this case. If the user cancels by just closing the page, then they will
obviously not see a message.

Turning This In - CRUCIAL DETAILS BELOW

To turn this in, you will need to upload all of your files (HTML, CSS, JS, PHP, images, etc.) to a Google
Drive folder. Create a new folder on Drive for this and be sure to share it with me. The file structure
(locations of files, and any subfolders) is also important, so you need to drag the entire project folder
into your Google Drive folder (don't just upload the files…include the entire structure). Your Google
Drive folder might look something like this (note the finalproject.sql file … important details follow):
Export Database
The last thing that you need to do is an export of your database; your pages work with your database,
your tables, your columns, your image filenames, etc., so I need your entire database as well. That is
what the finalproject.sql file in the image above represents.

IMPORTANT - Your database should be named finalproject. Note the name of the database in the
image below (left-hand side). You get to pick the names of your tables, but your database
should have the name finalproject.

To export your database (all of the tables, and the contents):

1. Make sure that you are in the correct database. At the top of the image above, you see which
database is selected (top-middle, next to Server: 127.0.0.1). If you aren't, click the finalproject
database in the left pane.
2. Find the Export tab in the options at the top (you can just see it above, on the right side edge).
3. The default options are perfect for this; don't change them (see the image) and then click the
Export button.

4. When you click that button, it will initiate a download in your browser. You need to upload this
file to your Google Drive folder. The default name for the file is finalproject.sql; it is okay if it
has a different name, but I'm trying to help you find it since the download was automatically
started for you (there isn't a chance to rename it before downloading it). Again, this file must be
included with your project when you upload your work.