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,
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
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
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
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
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
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
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.
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
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
this assignment. If you need help, ask the TAs!
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
'quit (with the implicit meaning). If the
'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
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).
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
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.
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
personal information page
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
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
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
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.