Many user interfaces are built to interact with a single user at a time: the user runs the software on their own machine, or from their own user account on a shared machine.
However, on the World Wide Web the applications run on a centralized location (which can have several machines), and users come in from all across the Internet. To make matters more complicated, a web application is usually not a simple, dedicated server that is run once per user: rather, each mouse-click on a button or hyperlink initiates a new HTTP connection which causes the gateway program to be run again, just to generate the next "screen" (usually an HTML document) that we want the user to see. This lack of one single, dedicated connection per user is the so-called stateless paradigm of the World Wide Web.
Also, the web application needs somewhere to put the search results, user preferences, shopping cart, and other data generated by a user in the course of their interaction with the system. The maintaining of user-private spaces for the duration of a user's interaction with a WWW-based system is often termed "session management." Typically, each user's session is distinguished by some form of unique "session id."
For example, in our Electronic Postcard application, we had to do a simple session management mechanism that passed along information that had to be remembered from one CGI program to another. However, in a more complex application (e.g. a web shop) the session management (e.g. remembering the contents of the shopping cart) is a much more complicated issue.
CGI programming doesn't offer any support for session management. Typically a session id is generated at the beginning of the session, and then embedded invisibly into the forms (or URLs) in all of the HTML pages returned to the client. The net effect is that whenever the user submits a form or presses a button that involves the system's CGI scripts, the session id is passed in as part of the request so the CGI script can "pick up where they left off." Another way is to use HTTP cookies for propagating the session id from screen to screen; however, not all browsers support cookies, and they can also be disabled.
However, the servlet API offers support for session management in a form of an HttpSession interface. The HttpSession interface provides an association between an HTTP client and HTTP server. This association, or session, persists over multiple connections and/or requests during a given time period. Sessions are used to maintain state and user identity across multiple page requests.
public class SessionServlet extends HttpServlet {
public void doGet (HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException
{
//Get the session object
HttpSession session = req.getSession(true);
...
A session can be maintained either by using cookies or by URL rewriting (embedding the session id in the URL). To expose whether the client supports cookies, HttpSession defines an isCookieSupportDetermined method and an isUsingCookies method.
HttpSession defines methods which store these types of data:
Standard session properties, such as an identifier for the session, and the context for the session. Application layer data, accessed using this interface and stored using a dictionary-like interface.
The following code snippet illustrates getting and setting the session data value.
//Get the session object - "request" represents the HTTP servlet request
HttpSession session = request.getSession(true);
//Get the session data value - an Integer object is read from
//the session, incremented, then written back to the session.
//sessiontest.counter identifies values in the session
Integer ival = (Integer) session.getValue("sessiontest.counter");
if (ival==null)
ival = new Integer(1);
else
ival = new Integer(ival.intValue() + 1);
session.putValue("sessiontest.counter", ival);
You could think about implementing a session management that stores information related to the user selections: what card was picked from the thumbnails list, information about the card, and the message entered. This is a nicer and easier way than passing along the information in the way you have done it with the CGI programs (for example embedding some values related to a card in the hidden fields of a form). Also, if the session is managed through cookies (depends whether your browser supports them) you could recognize a frequent user and offer him a personalized service based on selections he or she has done before.
For further information about session management look into the servlet API and the SessionServlet.java example.