Lab 1 - A Miniature On-Line Commerce Application
Due - February 9, at class time. See instructions below for electronic
submission.
Your company sells widgets. You decide to construct an on-line ordering system for your company. The first prototype of your Sales-Master system will handle only part of the problem - that is, maintaining the inventory of widgets left to sell. It is not required to capture the customer's address, etc. (That will come later.)
The customer first accesses a URL which invokes your first server software. This "server1.pl" opens an inventory file, which contains a single record that might look like
widgets=32
if you have 32 widgets still in stock. It then produces a dynamic HTML page which contains information something like this, if the inventory is >0:
Grading
I will try to get them graded by the class on 16 February. Please don't send me requests for a preliminary review saying "is this good enough?" because that doubles the number of things I have to look at. Have your friends check out the site, if you need that kind of feedback.
Note: You should read the requirements for Lab 2, and avoid implementing Lab 2's specific add-on features as "top 5% features" in Lab 1. Doing that makes it hard for me to grade Lab 2.
Lab 2: Commerce Gets Serious
The most obvious flaw in lab 1 was that we did not capture any information about the customer. In Lab 2, you will build a multi-stage system. Your company now sells three items: Economy Widgets, Ecology Widgets and Elite Widgets. You will create a first-page order form that ask for the customer's name, address, phone number and e-mail. Your software will check to see that this information is provided, and will reply with an error screen if anything is missing. If everything is as it should be, THEN your software sends the customer a second form, containing the order information.
The name and address data that was acquired during the first form will be hidden inside "hidden variables" and sent back out as part of the order form. Then, when the order comes back, if it contains no errors, a confirmation screen is sent. This confirmation screen contains the customer's address, and the order itemized. The customer is allowed at this point to click one of two SUBMIT buttons:
a) Change the Order
b) Submit the Final Order
If they click "Change the Order", they receive their order form, regenerated, so they can change it. If they click "Submit the Final Order", the inventory is decreased by the appropriate amount, and another confirming screen is sent out. This one will report that the order is being processed and will be shipped within 48 hours.
Finally, your software dumps into a text file (orders.txt) the order information for that customer, including the name, address, and what was ordered. To prove that this part of your lab works, you can enter an order into your system, then capture the orders.txt file and mail it to me, along with the URL for my testing.
Grading: You will mail me your URLs and sample order.txt files for Lab 2 during the 70 hour period between noon 6 March and 10 AM on Tuesday 9 March. Labs received after 9 March will be considered late and not eligible for more than 90% of full credit.
Comments about Lab 3: As you can see, your system is beginning to behave like a real commerce system. There are several issues left to explore, which (if you choose to do the On-Line Commerce System for your third lab) will occupy the rest of your semester. These are:
1) Soliciting a form of payment
2) Verifying payment by communicating with an online commerce system
3) Transitioning to a scripted, rather than an "ad hoc" system.
The first two ideas are pretty obvious, especially if you've looked at any of the registration screens at my www.regmaster.com site, or anywhere else on the Web. "Ad hoc" means special purpose; built for just one set of merchandise. By a scripted system, I mean that we will set things up so that your server software does not have to change when your merchandise changes. Your order form will be "streamed" from a source document, through the server, combined with the inventory file and a price table, and will appear as a full HTML form. Then, a company owner would only have to edit the source document and the price table, to change their line of merchandise.
If time permits, I hope to be able to emulate a credit card verification service (see www.cybercash.com) which you will access remotely.
But, we'll see how things develop after Spring Break.