ContentsApplication DesignExecution cycle

Previous: Thin pipes | Next: Usage scenarios

Our web clients communicate with the server-side components through HTTP. Since HTTP is a stateless protocol (meaning that there is no connection that is held from one screen to the next) we may need to save something on the client to identify it. On each successive screen of our application, we can use this identification to associate the user with their state and information that we've gathered from them so far.

This piece of information is a cookie. There is another approach that we could use, where we embed the identification into each web page that we send back (using a hidden form field); but the Java Servlet API gives us a handy mechanism that abstracts the cookies. This mechanism is called a "session".

When the user's web browser comes to our application, we will ask for their name and give them a cookie by instancing a new HttpSession object. In most servlet engines, this session object will automatically keep track of the user for us. We can store any additional objects about the session by using the methods provided on the session object.

In the case of our example, the user will first sign in, then will be provided with a form that lets them enter five years worth of data. This form also gives them three buttons where they can:

• cancel (which invalidates the session and returns them to the sign in screen)
• chart (which uses the data to produce the chart)
• enter more data (which gives them another form with places for five more years' worth of data)

With the PDF plug-in active, the application loses it's ability to provide navigation; so the best thing to do is to put the chart into an additional browser window. The user can then close the browser window or keep it around for comparison with subsequent presses of the "Chart" button.

Here's what the application looks like at this point -> code / output

Some points to ponder:

• session objects are used heavily in servlets, literally anything that has to do with the state of a user should be stored there
• there are different ways to organize your servlets, ranging from the encapsulation of each page within a separate servlet object to having the entire application defined by a single servlet (as is the case with this one)
• the state machine for your application needs to be defined somewhere (it's in the doPost method in this example)
• remember that other sessions may come and go within the life of any given session - don't make anything an instance variable unless your really understand the concurrence issues that may arise
• use constants such as the private static final String definitions for efficiency and to make your code more readable - especially in the case of key values for the state machine, getting HTML parameter values, and session values
• while you could whip out your calculator and supply constants for the width and height parameters on the constructor of the PdfChart object (line 181), the performance penalty for letting the JVM do this calculation is trivial; but leaving the expression in place will pay you back in maintainability

The servlet has the interaction behavior we want at this point, but no real output. Read on.

ContentsApplication DesignExecution cycle

Previous: Thin pipes | Next: Usage scenarios