Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 72 73 74 75 76 77 < 78 > 79 80 81 82 83 84 .. 166 >> Next

JSP turned out to be a set of challenges in its own right. Before discussing the blow by blow, let's quickly review the basics of Web application development.
Request/Response Paradigm
Web applications, independent of technological implementation, come down to a few fundamental concepts. Having built quite a few of these systems with a number of technological solutions, we've found that it boils down to a simple process:
¦¦ Parse parameters from request.
¦¦ Apply business logic (query/update the database in our case).
¦¦ Present results to the user in the response.
Listing 24.1 is an example of what this looks like in a servlet implementation.
01 public void doPost(HttpServletRequest request, HttpServletResponse
02 response) throws ServletException, IOException {
03
04 // Parse parameters from the request
05 String salary = request.getParameter("salary");
07
08 // Execute Business Logic (query a DB in this case)
09 try {
11 statement.setFloat(1, Float.parseFloat(salary));
12
13 // statement is a PreparedStatement initialized in the init() 2
method
14 ResultSet results =
15 statement.executeQuery();
Listing 24.1 doPost() from SalaryServlet
JSP Design Errors 209
16
17
18 // Present the results to the user in the response
19 response.setContentType("text/html");
20
21 PrintWriter out = response.getWriter();
22 out.println("<html>");
23 out.println("<head><title>SalaryServlet</title></head>");
24 out.println("<body>");
25 out.println("<table>");
26 out.println("<tr>");
27 out.println("<td><b>Employee</b></td></tr>");
28
29 while (results.next()) {
30 out.println("<tr>");
31 out.println("<td>");
32 out.println(results.getString(1));
33 out.println("</td>");
34 out.println("</tr>");
35 }
36
37 out.println("</table>");
38 out.println("</body></html>");
40 } catch ( SQLException sqle ) {
41
42 sqle.printStackTrace();
44 }
45
46 }
Listing 24.1 (continued)
Maintaining State
The other issue that comes up in building Web applications is that HTTP is a stateless protocol—that is, one request is independent of the next. Therefore, some method must be chosen to determine how to maintain information about what was done prior to and after this request. A classic example of maintaining state is the user login. A user should not need to provide a login credential with each request. Therefore, there must be some way of keeping track of whether or not this user has been authenticated. There are a few options for how to do this:
Passing parameters. Obviously, the Web application can pass the parameters with each request and embed "hidden" form elements in the response, so that the user doesn't need to re-enter these parameters. The obvious problem is that this can become quite burdensome, involving continuously passing information that is essentially passed through and not really relevant to this particular screen.
210 Item 24
Cookies. Cookies provide the ability to store pieces of information on the remote machine; therefore, the application can check to determine if it has previously set information on that machine. However, obviously, major concerns arise out of whether the user will allow such information to be set on his or her machine and how long such information can be counted on being available.
Session variables. HTTP actually provides the ability to put variables in the HTTP session; this was the mechanism that HTTP uses for its basic authentication scheme. Session variables can be helpful but can be problematic—especially with regard to maintaining the session and avoiding other variables with the same name.
JSP the Old Way
Let's take a second to discuss the evolution of Web applications. Originally, Web applications came in two forms: compiled executables (usually written in C or C++) and server scripts (usually written in Perl). They both used the Common Gateway Interface (CGI) to execute requests. To make Web applications easier to build, other scripting languages evolved like server-side JavaScript, JScript, and VBScript. The choice seemed to boil down to power (compiled code was always faster) versus ease of use.
The servlet implementation of my Web application brings me a number of advantages. It is compiled, so I get a performance increase. It operates in a shared process, the servlet engine, so it scales particularly well. Also, the shared process allows for the creation of shared resources like database connections. This is a particular advantage over previously compiled options, which would create new processes (and resources) to handle each request. This caused problems with scalability and with security (the command executed in its own space, without any managing thread to contain malignant or runaway code).
The problem with compiled code is that it is just that, compiled. Notice that I have embedded a great deal of HTML code into my servlet. That means any changes to the presentation require a recompile of the code. Furthermore, anyone who has created these out.println() commands of HTML understands the pain of escape sequences.
Previous << 1 .. 72 73 74 75 76 77 < 78 > 79 80 81 82 83 84 .. 166 >> Next