This is the fifth and last part of the project. Important things to remember:

1. Collaboration with anyone other than your partner is not allowed and will be considered cheating.
2. If you get stuck, or if any of the requirements seem unclear, ask for help!
3. Don't wait until the 28th to begin.

Read through the entire document before starting.

This is your term paper. It's fairly open-ended: you want to create an interesting, useful, user-friendly web-based application for using the MySQL database you created. Here are some guidelines:

1. You can use any programming/scripting languages or tools you like. Because of the infrastructure available, however, I strongly recommend that you use either CGI/Perl or (better yet) PHP. Even if you don't know these languages (particularly if you don't!), and you do know languages like C and Java (or maybe even Unix scripting), it will likely be much easier writing some new code in PHP than attemping the IT-related work of getting C or Java programs running on the webserver and talking to MySQL. (It would actually be interesting to see a solution based on another another language up and running--let a thousand flowers bloom and all that--but only PHP and Perl will be supported.)
2. Toy examples, in both PHP and CGI/Perl, of querying and updating our MySQL server are available here (select in Perl page/code, select in PHP page/code, insert/delete in Perl page/code, insert/delete in PHP page/code, master/detail in Perl page/code, master/detail in PHP page/code). Remember that PHP files, ending in .txt or not, will be garbled if you view them in your browser. Right-click and save the .txt PHPs and then view them in Pico or Textpad. Let me know if this doesn't work!

   These aren't very impressive visually (yet!), but they take an input and do something as a result of its value. The first step is to modify one of them so that it queries one of your tables (in your database) rather than mine. Once you have this working, everything else is just modification and combination of your working code.

3. The front page of your web-app should give the user at least five choices of queries (by whichever HTML means you like) to run. Important: the front-end should not look like SQL. It should offer choices to the user, ask for input (in the form of textboxes, checkboxes, radiobuttons, etc.), and generally provide a nice GUI.
4. MySQL does not support subqueries. Oh well. It does support GROUP BY, so at least one of your queries should use it. Your queries shouldn't be needlessly complex, but they shouldn't all be trivial SELECT * FROM A WHERE B='C's. SQL can be used to express lots of interesting queries. Be creative!
5. It is not required, but you can, for extra credit, have some of your interactions be inserts or deletes rather than queries. This requires more HTML coding (for more textboxes) and some security (i.e., user/pass prompt and cookies). Doing cookies or supporting updates (as opposed merely to inserts or deletes) would probably require more HTML than they're worth.
6. You might want to prevent against injection attacks. (Stay tuned!)

7. Your web-app has to work and be usable. When the user presses a button, something should happen. If, for some reason, you get a SQL error (like a failed connection), you should give an error message (use an OR die(...)). Strongly recommended: When you think you're done, have a friend (idealy, one who's non-technical) try to use it.
8. Neatness counts. HTML coding is not the primary focus of this course, but your webpages are publically available--in real life, they're one of an organization's most important public faces--so they should look presentable. That is, no typos, always having a link taking you back to the front page or a prompt asking for another choice, etc. Rule of thumb: Try to produce something that would look good, not embarrassing, linked to on your resume.

Deliverables:

1. A link to your web-app (which will be posted on the classpage)
2. An input producing a non-trivial result for each input textbox that doesn't return all results when left blank
3. A hardcopy of all sourcecode/scriptcode/HTML
4. A hardcopy of a readme briefly--O(1 page)--explaining
   1. which tools were used,
   2. what your webapp does vis-a-vis your database and
   3. specifically what sorts of queries/updates it uses