From The Brown Daily Herald, August 30, 2001 article on Brownisms:

Registrar: Michael Pesta — nice guy. We're the last school in the industrialized world where you still have to register in person [...]

Them's fightin' words.

In this assignment, we will implement a simple on-line registration program. Before we delve into the assignment, please note:

• You might wonder what this assignment can possibly have to do with programming languages. It actually has a lot to do with the course. I promise that you'll find out in the coming weeks, just not right now.
• You can implement part of this exercise in any language you wish. We won't penalize you for your choice of language(s). We only care about the quality of your solution.
• This assignment is hard, but not unreasonable. We're asking you to understand and use a standard Web protocol, and we're not even forcing you to deal with databases, concurrency, fault-tolerance, and so forth. A computer science concentrator should be able to implement this.

  Digression: What makes this assignment difficult is that the protocol offers you relatively little help with the hard parts. Don't you wish the protocol designers had put a little more effort into it up front? It's a lesson to keep in mind when you implement a (little) language and feel like cutting corners. Remember: interfaces last forever. Corollary: successful but bad interfaces hurt programmers for a long time!

• You will work in teams of two or three for this assignment. Yes, all of you. This is not optional. We will discuss team formation separately, but in the end, you are responsible for contacting us about it. We will not accept solo solutions.
• You don't need to do error checking — assume that inputs will not contain bizarre characters, for instance. You may also assume that servers do not go down (not realistic, but to design around that you need a lot more coursework).
• Don't spend time on cute HTML. It won't matter. If you do try to make your pages spiffy, be very sure to do so only after you've gotten the functionality correct. Features before correctness will incur stringent penalties. We've egressed our watery origins. We don't need fins.

We will update this page later with exact details of how to turn in your code.

A registry tends to be a fairly conservative place. The people who work there are suspicious of the Web. Therefore, they would like two versions of the program — one that runs with an old-fashioned text interface in a terminal, the other being your new-fangled Web version.

If you need help, contact the course teaching assistants, but do not contact the departmental or university systems staff. Even if you think the problem is at that level, ask the teaching assistants to contact the staff for you.

Part 1

You must do this part of the assignment in Scheme.

The purpose of this part of the assignment is really just to get you comfortable with writing various simple functions in Scheme. Get a lot of help from the TAs for this assignment if you wish. It is important that you write these functions and understand what you wrote; it isn't important that you spent a lot of time poring over Scheme manuals to figure out the details of the language. And do remember that you must use the design recipes for this and all other Scheme code.

Develop the primitive

prompt-read-many : list[string] -> list[symbol]
      

A prompt is a string informing the user what kind of input the program expects. The prompt-read-many procedure consumes a list of prompts, presents each prompt in turn, accepts user input, and gathers the input data into the result list. The answers in the result list should occur in the same order as their prompts are in the input list. You will also find the Scheme primitives read and printf useful in this assignment. If you need help, ask the TAs!

Use prompt-read-many to read in the student's name, street address and email address (all of which, for simplicity, we'll assume are symbols). Endow it with a boring, old-fashioned, terminal-based interface. We will henceforth call this a direct-style program.

With the student's personal data in hand, initiate a loop. In each iteration, you will display the list of courses the student has currently enrolled for, then the list of courses that the student hasn't enrolled for. (Each course name is a symbol; make up as many courses with whatever names you wish.) Then use prompt-read-many with two prompts: the first asks for their next operation, and the second for a course name. Legal operations are 'add, 'drop or 'quit (with the implicit meaning). If the operation is 'quit, ignore whatever they type for the course name.

When the student indicates they wish to quit the loop, print out a simple summary that includes their personal information (name, street address and email address) as well as their final course selection list.

When you run the program, you might see a transcript like this. Notice that I generously use Scheme's ability to print list information using parentheses. You can do the same (and should, to save your time for the hard part).

Part 2

You may use any programming language(s) you choose to solve this part of the assignment.

In this part of the assignment, you will develop a series of ``Web scripts'', or programs that obey the CGI protocol. We've provided information on the CGI protocol and the department's policy below.

This part consists of two sub-parts that build toward a fairly complete solution to the registration problem. You need to submit solutions to each part. You would be best off doing these in order.

1. Generate a Web form with fields for the student's personal information (name, street address, email address). When the student submits the form, this page merely prints the information the student just entered. It has no additional functionality. We'll call this terminal page the sign-off page.
   Example:
   personal information page — sign-off page
2. Extend the previous solution in the following ways.
   • Every student who completes the personal information form can enroll in courses. The second page is now a form. It prints the student's personal information and their enrollment choices (initially no courses, as in Part 1). It offers a choice of three actions: add, drop and quit. It also has a field for specifying a course name for the first two options. (Note: you may not use check boxes for specifying the course names.)
   • Submitting an add or drop request now generates a fresh copy of the same form. The personal information remains the same, while the enrollment choices are updated to reflect the choice just made. Students can thus enroll in several courses, and add and drop courses at will until they're happy with their selection.
   • The sign-off page now lists the personal information and the student's final course selection for the semester. (It can list more, as in my example, but it doesn't need to.)
   
   Example:
   personal information page — initial content of second page — after adding cs18 — after adding cs31 — after signing off

The last version of your program reflects a fairly good approximation to an on-line registration system. Or does it? Think about each of the following:

• Users sometimes interrupt their browsing to bookmark a page, then return to it later. When they return, they expect to not have to re-enter the data they have provided earlier (in this case, personal information and the enrollment choices). Does your solution pass the Bookmark Test?
• Users sometimes initate an operation (such as adding a course), dislike the result they see (maybe too heavy a course load) and use the browser's Back button (or equivalent) expecting it to undo the operation. Does your solution pass the Back Button Test? That is, if a student adds a course, backs out, then adds a different course, the aborted exploration should not show up on the roster.

About CGI Programs

Here's the default reference on CGI. CGI being about the Web, there's no shortage of documents on the Web that describe how you can program in this protocol.

If you choose to develop your software within the Brown computer science department, please obey our policies. Please don't put these programs on the Outside Web. They really don't belong there.

In general, please realize that CGI programs can cause breaches in system security. The risk is even greater here, because you're assuming that inputs will be well-formed. Carelessness can endanger your entire host system.