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 .. 108 109 110 111 112 113 < 114 > 115 116 117 118 119 120 .. 166 >> Next

Request to purchace tickets for Led Zeppelin SessionSerulet::doGet
Request to purchace tickets for Alicia Keys
j
Figure 36.1 Processing simple submissions.
314 Item 36
Preventing Multiple Submits
The first and most effective way to handle the multiple-submit problem is to not allow it to happen in the first place. Listing 36.1 shows the underlying HTML for a simple form that captures the name of a concert and submits it to a servlet to order tickets. The form works perfectly fine when the Web site performs adequately speedwise. However, if the Web site bogs down and the submit is not processed quickly enough, the user gets frustrated and processing such as that shown in Figure 36.2 results; the submit happens over and over.
01 <HTML>
02 <HEAD><TITLE>Online Concert Tickets</TITLE></HEAD>
03
04 <CENTER><H1>Order Tickets</H1></CENTER>
05
06 <FORM NaME="Order" ACTION="./SimpleOrder" METHOD="GET">
07 <TABLE BORDER="2" WIDTH="50%" ALIGN="CENTER" BGCOLOR="CCCCCC">
08 <TR><TD ALIGN="RIGHT" WIDTH="40%">Concert: </TD>
09 <TD WIDTH="60%"><INPUT TYPE="TEXT" NAME="Concert" 2
VALUE=""></TD></TR>
10
11 <TR><TD COLSPAN="2" ALIGN="CENTER">
12 <INPUT TYPE="submit" NAME="btnSubmit"
13 VALUE="Do Submit"></TD></TR>
14 </TABLE>
15 </FORM>
16 </BODY>
17 </HTML>
Listing 36.1 ConcertTickets.html form
c C:\WINNT\5ystem32\cmd.exe - startWebLogic.cmd
jnjxj
SessionSerulet::doGet
Request to purcbace tickets for ozzy
< Jan 12, ?.m?. 2:43:19 PM EST> <Info> <HTTP> < [We bAppServletContext <6559849, ltWebApp,/DefaultWebApp)] SimpleOrderSerulet: destroy>
< Jan 12, 2002 2:43:19 PM EST> <Info> <HTTP> <[UcbAppSeruletContext<6559849,
1 tUebApp,/Def au 11WebApp> J SinpleOi'derSerulet: init>
SessionSerulet::doGet
Request to purcbace tickets for ozzy
Sleeping for 15 seconds
Sess ionSerulet::doGet
Request to purcbace tickets for ozzy
Sleeping for 15 seconds
Sess ionSorulet::doGet
Request to purcbace tickets for ozzy
Sleeping for 15 seconds
Sess ionServlet::doGet
Request to purcbace tickets for ozzy
Sleeping for 15 seconds
SessionSerulet::doGet
Request to purcbace tickets for ozzy
Sleeping for 15 seconds
SessionSerulet::doGet
Request to purcbace tickets for ozzy Sleeping for 15 seconds
Def au Def au
Figure 36.2 Repeated submissions.
Too Many Submits 315
As we said, the simplest way to handle the multiple-submit problem is to stop it from happening. Listing 36.2 shows a subtly different version of our concert order form—one that has a small amount of embedded Java script. The embedded Java script "remembers" if the Submit button was previously pressed, and if so, an alert pops up and the submit isn't processed. We short-circuit the normal submit processing by adding an onClick attribute to the Submit button. Every time the button is pressed, the code described in the onClick is processed. In our case this results in the JavaScript checksubmitcount() method being called. However, just calling a function doesn't really help. If we did no more then add the onClick, we'd get our popup alert box every time the Submit button was pressed, and then immediately the submit would happen. The user would be alerted that he or she made a mistake, and the request would be sent anyway. This is an improvement over our prior problem, but only from the user's perspective; the end result was the same: multiple submits.
We can solve the problem by going one step further and subtly changing the way our page works. Sharp readers might have noticed the one additional change. The type of our button, line 12, was originally "submit," but now it is replaced by "button." The look and feel of the page is identical. However, the default action associated with the form, shown on line 6 of Listing 36.1, to invoke the servlet, is no longer automatic. We can now programmatically choose to submit the form to our server, and our problem is solved. Or is it?
01 <HTML>
. .<!-- repeated code removed //-->
12 <INPUT TYPE="button" NAME="btnSubmit"
13 VALUE="Do Submit"
14 onClick="checksubmitcount();"></TD></TR>
15 </TABLE>
16 </FORM>
17
18 <SCRIPT LANGUAGE="JAVASCRIPT">
19 <!--
20 var submitcount = 0;
21 function checksubmitcount()
22 {
23 submitcount++;
24 if (1 == submitcount )
25 {
26 document.Order.submit();
27 }
28 else
29 {
30 if ( 2 == submitcount)
31 alert("You have already submitted this form");
32 else
33 alert("You have submitted this form "
34 + submitcount.toString()
35 + " times already");
Listing 36.2 Concert2.html form (continued)
316 Item 36
36 }
37 }
38 //-->
39 </SCRIPT>
40 </BODY>
41 </HTML>
Listing 36.2 (continued)
Handling Multiple Submits
Listing 36.2 was certainly an improvement, but we've still got a ways to go. A number of issues still could go wrong. For example, what if the user pushes the back button and starts over? What if his or her browser has JavaScript disabled, or for some other reason, handling the processing in the browser cannot be used? We can still solve the problem, but now instead of preventing multiple submits, we need to handle them on the back end, via the servlet that processes the form.
Previous << 1 .. 108 109 110 111 112 113 < 114 > 115 116 117 118 119 120 .. 166 >> Next