Download (direct link):
Listing 25.4 sends the user to the showNewbieTheSite() method if the isNew() method of HttpSession returns true on line 13. Also, it tests to see if the customer's name is in the HttpSession on lines 19 to 21. If the getValue() method returns null, then we know that although the session is not new, the user has not set up an account with the current e-commerce application.
01 public void doGet(HttpServletRequest request,
02 HttpServletResponse response)
03 throws ServletException, IOException
05 PrintWriter out;
06 HttpSession session = request.getSession(true);
07 Vector shoppingcart = null;
10 out = response.getWriter();
12 out.println("<BODY BGCOLOR='WHITE'>");
13 if (session.isNew())
Listing 25.4 A smarter way for assuming past usage
When Applets Go Bad 227
19 String name =(String)session.getValue(
22 if (name == null)
24 /* Here, the person might have an existing session,
25 * but not with us!
32 /* NOW we can assume that they've visited the site! */
33 out.println("<H1>Welcome back, " + name + "!</H1>");
34 shoppingcart = (Vector)session.getValue("shoppingcart");
35 if (shoppingcart != null)
37 out.println("You have " + shoppingcart.size() +
38 " left in your shopping cart!");
42 //more code would follow here..
Listing 25.4 (continued)
Finally, lines 32 to 40 can assume that the user has used the e-commerce application before!
In conclusion, be careful about your use of HttpSession in servlets. Be aware of the collision pitfalls that could await you in regard to naming data objects with put-Value(), terminating the session with invalidate!), and testing for first-time use of the session with the isNew() method.
Item 26: When Applets Go Bad
In the pitfall "J2EE Architecture Considerations" (Item 37) in Part Three, we discuss a software project where we had proposed a solution that can be viewed like Figure 26.1. In that pitfall, we discuss the several scenarios for the client-side behaviors.
228 Item 26
Figure 26.1 The proposed system.
Analyzing the requirements, we found there were really two types of users envisioned for this system. There were analyst personnel who needed a rich toolset by which they could pour through this voluminous set of data. Also, management personnel needed an executive-level summary of system performance. Therefore, there were truly two different clients that needed to be Web-enabled.
The analyst client needed functionality that included mapping, time lines, and spreadsheets. This was going to be the primary tool used for these personnel to perform their job and was expected to perform like the rest of the applications on their desktop machine. They wanted to be able to print reports, save their work, and most other things that users have come to expect from their PCs.
The manager client was meant to show some commonly generated displays and reports. Essentially, this would be similar to portfolio summary and headlines views. They didn't want anything more involved than pointing their Web browser at a Web site and knowing the latest information.
When Applets Go Bad 229
It was critical that the application needed to be centrally managed. Since the analysts were a widely distributed group, there could not be any expectation of doing desktop support or ensuring that the proper version or update was installed.
So we built an applet for the analyst's toolkit. Immediately, we noticed a number of problems with the applet:
It was approximately 3 MB in size. No matter what we looked at, the time line, graphing, and mapping components were simply too large to allow us to reduce the size any more. We tried a phased loading approach, but that didn't really help much; since this was a visualization suite, we couldn't really backgroundload anything.
The JVM versions were problematic. Moving to the Java plug-in was better, but we still had small subtleties that bothered us. Applets run within the context of the browser; even with the plug-in, they are still at the mercy of the browser's handling.
The security model was buggy and convoluted. Trying to assign permissions inside something that runs within the context of another application is fraught with issues. We had problems with saving and printing from the applet. The biggest showstopper was the fact that our Web server ran on a separate host than the database server. So if we couldn't get the permissions problem to work out, we would not be able to attach to the DB server at all. We intended to use a database access servlet, but we didn't want our hand forced this way over something that should work.
The application ran into responsiveness problems. It had buggy behavior about being unable to find a class that was not repeatable. However, it seemed these problems went away when it was run from an application.