A college, to attract more students, has decided to offer free pizza in the dormitory. You have been selected to implement the needed automated ordering system.The pizzas will be available in 2 sizes, Small or Large. Toppings beyond the basic tomato sauce and cheese can be selected from an expandable set of options:
That is, a student can order any subset of these toppings, or none at
all. The dormitory room number and current day is remembered as
well. The students should be able to ask (by room number) if their pizza
is done, and its size and toppings, i.e., all information on pizzas
ordered so far today for this room. When a student acknowledges
receipt of the pizza(s) for a room, those pizza orders are
marked completed. The students are assigned usernames by the
admin for use in this system.
The pizza shop admin tells the system when the next pizza is done (they come out of the oven in order), and when a day is done. When a day is done, all the orders are complete for that day.
The pizza shop admin can add and delete toppings and set up shop from scratch. Also, the admin should be able to ask for information on all the pizzas ordered so far today that are not yet complete, the “in progress” orders.
Pizzas are tracked in the system by their status: Preparing just after order is placed, Baked a while later, Finished after receipt by student or end of day. Days are tracked by simple day number that is incremented by the admin’s finish-day action.
Actions for Students, once identified by username:
This is all about the pizzas ordered for one user. We could ask the user “up front” for his/her username, but websites normally allow users to proceed without identifying themselves until an actual order is in the works, so we first display info that doesn’t require knowing the username on the student-welcome page, that is, the choice of toppings and sizes, with a link to order a pizza. On the order form, the user selects their username along with the choice of toppings and size. When the order is submitted, control returns to the student-welcome page, where now the newly submitted order is displayed as an order for this room, along with all the other elements previously listed for the student-welcome page. In fact, the user can identify themselves right on the student-welcome page if they want.
Actions for Admins
When the order is new, it has status Preparing . At some point, the admin uses a command (see above) that changes its status to Baked, that is, ready for delivery. When the pizza is delivered to the room (each student has a room number in the database), the student is expected to acknowledge its receipt, and then its status changes to Finished. The student can see the current status of the ordered pizza by refreshing the student-welcome page, since it displays the status of all of today’s pizza orders for this room. If there are any Baked pizzas in this list, a button should appear to acknowledge receipt of such pizza(s).
Note the correspondence between the student pages here and the product pages in the product_manager of ch05_guitar_shop. Both use just two pages, one to list the objects of interest to the user and another to help add/delete another object to/from the list. Nowhere is the user presented with the raw list of actions.
When designing modern user interfaces, think objects, then actions. Looking at the admin actions, we see they can be grouped as involving objects that are toppings, users, orders, and days. Of course the most important orders are the ones in progress, which are affected by the Mark and Finish-day commands. Thus we propose the top-level topics:
In addition, we need to be able to reinitialize the database, for testing purposes (during development). In production, the initialization is done by a special procedure.
This is something like the categories in the product_catalog UI. Note how the categories are handled by a sidebar. Similarly provide a sidebar for the admin pages with a link to order pizzas, plus a link to the site home (same as sidebar for student pages.)
If the (admin) user selects Orders, the list of Preparing and Baked orders are shown, and a button is provided for marking the oldest Preparing one baked. In either case, the modified lists of in-progress orders are shown.
If the user selects Days, today’s day number is shown, with a button to advance it to the next day. Today’s orders are shown, of all status values.
Architecture and Organization: for Project 1, we will follow the patterns implemented in ch05_guitar_shop:
MVC: all HTML-generating PHP (the view code) will be in separate source files from controller code, itself in “index.php” files.
All database access will be handled in the model code, in the model directory. All shared (between users) variable data is held in the database.
View code will be stored in the same directory as the index.php that controls it, unless it is view code that is included from code in more than one directory, like header.php and footer.php, in which case it is stored in the view directory.
There is one top-level index.php that has links for all the major activities of this application: student operations and admin managers for toppings, users, orders, and days.
Like product_catalog in ch05_guitar_shop, there is a “pizza” directory, containing an index.php to control the actions for students. Views involved in this activity are in other files in this directory.
Like product_manager in ch05_guitar_shop, an admin-related directory, the pizza project has several admin-related directories, each containing an index.php to control the actions for admins. Views involved in this activity are in other files in this directory. The admin directories handle each of the four management activities, toppings, users, orders, and days.