CS 1102 (A12) Lab 6: Web Programming

To get your participation credit, make sure you
upload your Definitions file to turnin before you leave the lab!
(This work will not be graded---full credit just for submitting.)

Lab Motivation and Goals

This lab looks at the problems with managing state information when programming on the web, specifically at the need for "hidden fields" in forms.

As a motivating example, let's consider the following bad experience reserving a hotel on the web (which can actually happen if you disobey the Don't Press the Back Button! admonition on poorly coded web sites):

  1. You search for hotels in a given city and then view the details for Hotel1 in a new window (or tab), leaving the original search window open.
  2. You similarly view the details for Hotel2 in a new window (leaving the search window and Hotel1 detail windows open).
  3. You navigate back to the Hotel1 details window (using Back button or selecting tabs/windows) and click on the button to reserve a room.
  4. You receive confirmation of a reservation at Hotel2.

You need to use the Pretty Big language level for this lab.

See hints for using HTML in Racket.


Put your name in a comment at the top of the Definitions area.

Download the starter file for this lab and the simple http server from class and make sure they are both in the same folder (e.g., both on the desktop). Load and run only the starter file in DrRacket.

In the starter file, you will find data definitions for a trivial hotel database and two versions of an interactive application related to the motivating example above.

  1. Version 1 is a straightforward GUI program, written in the functional style we have been using in class, which a software engineer might write as a mockup to explain the desired functionality to her manager. Run the (hotel-main-page) function several times with various choices to familiarize yourself with the prompts and behaviors. (Note that this program does not have very good error checking, because we want to keep it short and it's only a mockup.)

  2. After the mockup is approved by management, our intrepid software engineer writes Version 2, which is the "real" web version that can be run with our simple http server using port 8088.

  3. Reproduce the bad experience in the motivation section above as follows:

    The problem here is that navigating between tabs/windows is a "silent" operation---it happens totally in the browser, so that the server has no way of knowing something has changed. This has exposed a poor design in which information that should be part of the environment of a given page is instead being shared as global state via a cookie.

  4. Edit Version 2 to fix the bad experience above, i.e., in the last step you should have a reservation at the Hilton.

    Hint: Get rid of the cookie and instead add a hidden field ([type "hidden"]) to the second form to remember the hotel choice. A hidden field holds a value just like any other field, but does not cause a type-in field to be displayed.

    Run your revised code with the same sequence of interaction as above and confirm that you have a reservation at the Hilton.

    Everybody should be able to finish up to this point.

  5. It would be nice if the hotel main page displayed all your current hotel reservations. Revise your code to provide this feature. Hint: This would be a good use for a cookie. Why? (You may want to look at the original starter file with cookies to see how to read and write cookies.)

    Warning: Don't put any special characters, such as [ or \, in cookie values, unless you want to look up the special quotation rules, which are not important for this lab.

Back to the labs page