< Zurück | Inhalt | Weiter >

18.6.1 Cookies

For any information that you want to save for longer than the duration of a session, you may want to investigate cookies—little bits of data (4K max; typi- cally only a few bytes) sent to the browser for it to store and send back at a later time. You make a cookie thus:


image

2. You can go to another page, just be staring at the page for a long long time, or you might have shut down your browser completely—and the server-side servlet will never know.


Cookie snack = new Cookie("name", "value"); snack.setMaxAge(36000); // lifetime in seconds (10 hours)


Setting the maximum age of the cookie to a positive value is needed to let the browser know that it needs to store the cookie on disk. After that many seconds the cookie will be discarded by the browser as no longer relevant. No- tice, too, that you must send the data inside the cookie as a string, and when you retrieve it, you’ll have to parse that string.

Then you can send the cookie as part of a response, along with your other output:


response.addCookie(snack);


Getting data back via cookies involves requesting data from the HttpServletRequest object. All the cookies associated with your URL are sent with the HTTP header to this address. You make the call:


Cookies [] allSuch = request.getCookies();


and then you have to look through the list looking for the cookie you want:


if (allSuch != null) {

for(i=0; i allSuch.length; i++) { Cookie c1 = allSuch[i];

if ("DesiredCookieName".equals(c1.getName())) { String result = c1.getValue();

// ... now do something with it

} // endif

} // next cookie

} // endif


While cookies have gotten a lot of press, especially in the early days of Web technology, we’ve found much less use for them than for session objects. Session objects stay on the server, cannot be modified or deleted by the user, and are easier to look up and use. The drawback, or course, is their limited lifespan. But if you really want to leave data around for the next time some user visits your servlet, you may be better off putting the data in your own database and identifying that user by means of a cookie or by some login mechanism.

Let’s take a look at a complete servlet example.


18.7 DESIGNING A BUDGETPRO SERVLET


When designing a servlet, there are many different patterns to follow. We can’t hope to cover all the approaches that can be used for effective servlet program- ming. What we hope to do is show you our previous BudgetPro GUI applica- tion rewritten as a servlet, so that you can see the mechanics of a working servlet application. From this, you can become accustomed to the mechanics of a servlet so that you’ll feel comfortable with other approaches, too. All servlets need to use these basic mechanisms.

Our BudgetPro GUI application was started from the command line, with a name for the budget and a total dollar amount. We’ll use a static HTML page with a form for supplying that information. That will invoke our servlet. The servlet will use HTML pages analogous to the windows we used in our GUI—there will be a main screen that shows the current account listing its subaccounts, and there will also be a screen for creating new subaccounts.

One nice feature of HTML-based Web applications is that you can use hyperlinks as a way to both select something and take an action on it. We’ll use that feature in lieu of a View Subaccount button. Instead of selecting a subac- count and then pressing View Subaccount, the user will only have to click on the name of the subaccount. As a hyperlink, it will make the request to the servlet to view that subaccount.

We will still use a button to send us to the screen for creating the subac- counts. We could have used a hyperlink, but this makes the browser page look a bit more like the GUI version.